Uptime Monitoring

Uptime Monitoring That Does Not Cry Wolf

A monitor is only useful if you trust it. SutramX runs high-frequency HTTP/HTTPS checks, retries a failure and, on paid plans, confirms it from more than one region before it ever reaches your phone — so an alert means something is genuinely broken.

In short

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.
ProbefiresCheckfailsQuorumconfirmsAlertdispatches

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

ProtocolsHTTP, HTTPS
MethodsGET, POST, PUT, PATCH, HEAD, DELETE
Check intervalFrom 15 s (Pro), 30 s (Growth), 60 s (Starter) or 3 min (Free), up to 15 minutes
AssertionsStatus code, keyword/regex body match, max response time
Timing breakdownDNS, TCP, TLS, TTFB, total
Retry policyCross-region confirmation before state change

Learn more

Related capabilities

Know it’s down before your customers do.

Start free — Free plan forever, no card required. Upgrade any time.