Use Cases

What You Monitor Depends on What Breaks You

A checkout outage and a stale search index cost very different things. These pages cover what to watch, at what interval, and why — for three common situations.

Which page fits you

The monitors are the same in every case. What changes is which endpoints matter, how quickly you need to know, and who has to hear about it.

  • SaaS platformsFor teams whose customers build their work on the product. The focus is the login path, the public API your customers integrate against, failures that only affect one region, and an independent record of uptime when you publish an SLA.
  • E-commerceFor stores where an outage has a price per minute. The focus is the whole buying path, from product page to cart to checkout, payment callbacks that fail without any visible error, search that returns nothing, and getting ready before a sales peak.
  • Developers and side projectsFor one person who is the whole on-call rota. The focus is the quiet failures: a sleeping database, a suspended free tier, a cron job that stopped running. Free includes 50 monitors checked every 3 minutes from 1 region, 1 status page, which covers most side projects.

If you are not sure which applies, start from what hurts most when it breaks. Lost sign-ins and broken integrations point to the SaaS page; lost orders point to e-commerce; finding out weeks later that something stopped points to the developer page. Plenty of products are a mix, such as a SaaS product with its own checkout, and reading two of these pages is the quickest way to build a sensible first set of monitors.

Whichever page fits, the same three decisions follow: how often to check (see choosing check intervals), how to keep alerts trustworthy (reducing false alerts), and where alerts go (alert integrations for Slack, Teams, Telegram and more). The feature overview covers every monitor type in one place.

Common Questions

Frequently Asked Questions

Which pages should I monitor first?
Start with the one whose failure costs you most. For a SaaS product that is the login path and the public API; for an online store, the checkout and the payment callback; for a side project, the main URL and a health endpoint that touches the database. Then work outwards to the pages that matter less.
How often should each page be checked?
Match the interval to the cost of not knowing. Login and checkout paths are worth checking every 15 to 60 seconds, a marketing site every few minutes, and a side project with modest traffic is well served by the Free plan's interval. SutramX checks can run as often as 15 seconds on Pro, 30 seconds on Growth, 60 seconds on Starter and 3 minutes on Free. Try the check interval planner
Can one account cover more than one of these situations?
Yes. Monitors are not tied to a use case, so a SaaS product with a checkout can watch both its login path and its payment callback from one account, within the plan's monitor limit. Team seats are unlimited on every plan.
How do I catch a page that returns 200 but is broken?
Add a keyword or response-body assertion. A site search that returns an empty result set, or an API that answers 200 with an error inside, looks healthy to a status-code check. Requiring a known word or value in the response turns that into a failed check. How API assertions work

Know it’s down before your customers do.

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