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 immediately re-checks from additional regions before changing the monitor state. Only when enough independent vantage points agree does the monitor transition to DOWN and dispatch alerts. If they disagree, the event is recorded as a regional anomaly you can review later — without waking anyone.
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 | 10s – 60m depending on plan |
| 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 |