SutramX uptime monitoring sends HTTP or HTTPS requests to your website or endpoint as often as every 15 seconds (Pro), checks the status code, an optional keyword and the response time, and times DNS, connect, TLS and first byte separately. A failed check is retried, and on multi-region plans confirmed by other regions, before anyone is alerted.
How a check actually runs
Every monitor is a scheduled job that resolves DNS, opens a TCP connection, completes the TLS handshake where applicable, sends your configured request, and reads the response. Each of those stages is timed separately, which is what lets you tell a slow database apart from a slow DNS resolver.
A check is graded against the conditions you set: an expected status code or range, an optional body assertion, and a maximum acceptable response time. Failing any one of them marks that individual probe result as failed — not the monitor.
- DNS resolutionMeasured separately so resolver problems do not masquerade as application latency.
- TCP connectReveals network path and connection-pool exhaustion issues.
- TLS handshakeSurfaces certificate and cipher negotiation cost, and catches expiry-adjacent failures early.
- Time to first byteThe number that usually correlates with what your users actually feel.
Confirmation: why you are not paged on the first failure
The internet is unreliable in small, boring ways. A single transient packet loss event between one probe region and your origin is not an outage, but a naive monitor will treat it as one. That is the root cause of most alert fatigue.
When a probe fails, SutramX retries that check once from the same region about two seconds later before recording it. On plans with more than one region, the monitor goes down only when enough regions have recorded the failure. A failure seen by fewer regions stays a regional anomaly you can review later.
Recovery and flap suppression
Recovery uses the same logic in reverse: a single successful check does not immediately clear an incident, which prevents an endpoint that is oscillating between healthy and broken from generating a stream of up/down notifications.
Monitors that change state repeatedly in a short window are marked as flapping. You still get the first alert, but subsequent transitions are collapsed into a single ongoing incident until the endpoint stabilises.
Specifications
| Protocols | HTTP, HTTPS |
|---|---|
| Methods | GET, POST, PUT, PATCH, HEAD, DELETE |
| Check interval | From 15 s (Pro), 30 s (Growth), 60 s (Starter) or 3 min (Free), up to 15 minutes |
| Assertions | Status code, keyword/regex body match, max response time |
| Timing breakdown | DNS, TCP, TLS, TTFB, total |
| Retry policy | Cross-region confirmation before state change |
Learn more
- Guides: What Is Uptime Monitoring?, Choosing Check Intervals, Uptime Monitoring Services Compared, Synthetic vs Real User Monitoring and Why Is My Website Down?
- Free tools: Website Uptime Checker
- Use cases: Monitoring for E-Commerce
- Comparisons: SutramX vs UptimeRobot and SutramX vs Pingdom
- Documentation: HTTP & keyword