PricingStatus
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 from multiple regions and confirms a failure before it ever reaches your phone — so an alert means something is genuinely broken.

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

ProtocolsHTTP, HTTPS
MethodsGET, POST, PUT, PATCH, HEAD, DELETE
Check interval10s – 60m depending on plan
AssertionsStatus code, keyword/regex body match, max response time
Timing breakdownDNS, TCP, TLS, TTFB, total
Retry policyCross-region confirmation before state change

Related capabilities

Ready to stop finding out from your customers?

Join the waitlist before September 5, 2026 and get a full year of Pro free — no credit card, no commitment.

See Pricing