Product study · 2026
SutramX
How we designed and engineered an uptime monitor whose alerts can be trusted — confirmation before alerting, and an explanation attached to every incident.
- Product strategy
- Product design
- SaaS engineering
api.example.com/health
HTTPS · API monitor
- FrankfurtTimeout
- ArizonaTimeout
- Mumbai200 OK
- Quorum
- 2 of 3 regions agree
- Failure class
- Timeout
Verdict
Likely external — not your code
Illustrative alert
Monitoring people can actually trust.
Most teams follow the same arc with monitoring: set it up, get flooded with false alarms, silence the alerts, and go back to hearing about outages from customers. The root cause is usually structural — a single checking location treating one failed request as an outage. SutramX is our answer: synthetic monitoring for websites, APIs, cron jobs, servers, SSL certificates and domains, built on the belief that an alert you can’t trust is worse than no alert at all.
Send fewer alerts, make every one of them trustworthy, and tell the team why it fired — what failed, where, and whether it looks like their fault, a vendor’s or the network’s.
How we approached it.
- 01
Confirm before alerting
A failed check is retried from the same region about two seconds later before it counts. On multi-region plans, an incident opens only when enough live regions see the failure at the same time. We accepted a few seconds of extra detection time in exchange for removing most false pages.
- 02
Explain every alert
Every incident carries its reasoning: each region’s result, the quorum rule applied, the failure class, and why an alert was or wasn’t sent. It is rules-based rather than a black box, and it ships on every plan, including Free.
- 03
Separate their outage from yours
When a vendor such as a payments provider, an AI API or a cloud region fails for several customers at once, SutramX labels the incident likely external — so a team stops debugging code that isn’t broken.
- 04
Price without dark patterns
A genuine free plan with 50 monitors and no card, clear limits, unlimited seats on every plan and no surprise overage bills. Pricing is part of the product, so we designed it with the same care.
The operating areas brought together.
- Checks from three regions
- Frankfurt, Arizona and Mumbai, checking as often as every 15 seconds, measured from outside the customer’s infrastructure — no agent, SDK or code change.
- Nine monitor types
- HTTP/HTTPS, APIs with assertions, keyword, ping, TCP and UDP ports, cron and heartbeat, DNS records and remote MCP servers.
- Fourteen alert channels
- From email and Slack to WhatsApp, voice calls, PagerDuty and Opsgenie — one alert thread per incident, with escalation when nobody acknowledges.
- Status pages
- Live monitor states, daily uptime bars and incident updates, hosted independently of the systems they report on.
- Reliability insights
- Deploys linked to incidents, SLO error budgets, monitor dependencies for one root-cause alert, and weekly reports.
- Recovery and flapping rules
- Recovery needs confirming too, and a monitor that fails again within five minutes of recovering doesn’t send a repeat alert.
How the product holds together.
The hard part is not sending an alert — it is deciding when not to. Quorum, retries, reduced-coverage rules and recovery confirmation are encoded as explicit, inspectable rules, so the product can always show its reasoning to the person it just woke up.
Let’s build yours next.
SutramX is our whole practice in one product — definition, interface design, engineering, pricing and ongoing operation. It is the same approach we bring to every client engagement.