Tallwatch
Back to blog
2 min read
Uptime monitoringGuide

What should you actually monitor on a SaaS (and what to skip at first)

You do not need fifty monitors on day one. You need the few URLs that, if they died, would make customers leave — and honest rules for adding the rest later.

NK

Nabin Khair

Founder

What should you actually monitor on a SaaS (and what to skip at first)

New teams either monitor nothing or monitor everything. Both fail. Nothing means customers are your detection layer. Everything means the pager fires for pages nobody will fix tonight, and soon nobody believes the pager at all.

The day-one list

Put external checks on:

  1. Login or session bootstrap — if people cannot get in, nothing else matters.
  2. The main app shell or primary API health URL — whatever "the product works" means in one request.
  3. Checkout, billing portal, or payment webhook receiver — if money touches it, watch it.
  4. Your public status page — on separate infrastructure if you can. When the product is down, this is how you talk.

That is enough for an early SaaS. Four good monitors beat forty mediocre ones.

What to skip until it hurts

  • Marketing homepage only, if login and API are already covered and the marketing site is static elsewhere.
  • Every internal admin route.
  • Every microservice behind the gateway you already check.
  • Staging, unless someone gets paid to wake up for staging.
  • Third-party status URLs you do not own — subscribe to their status page; do not invent a second pager for Stripe's incidents unless you have a real playbook.

If a check fails and the runbook is "shrug, wait for the vendor," it should not wake a human.

How to grow the list

Add a monitor when you can finish this sentence: If this breaks at 2am, the on-call person will ___.

Ship a new critical customer flow → add it.
Get burned by an SSL expiry → add an SSL expiry monitor (or watch the HTTPS URL that fails when certs expire).
Ship a cron that must run nightly → add a heartbeat.
Enterprise customer asks for component-level status → split status page components and back each with a check.

Do not add monitors because a competitor's marketing page shows a big number.

One rule that keeps the list honest

Every monitor should have an owner and a next step. Owner can be "whoever is on-call." Next step can be a three-line runbook. No owner and no next step means the alert is decoration.

On Tallwatch I would rather you use ten free monitors on the paths that matter than fill the board with noise. Coverage is not the same thing as care.

Related

Keep reading

False alerts and status pages.

How to migrate off a free uptime tool without a lost weekend

How to migrate off a free uptime tool without a lost weekend

Leaving a free checker does not require a hero migration. Run both in parallel, match URLs, and cut over when the new pager has earned trust.

NKNabin Khair
Website slow vs website down — how to tell which problem you have

Website slow vs website down — how to tell which problem you have

Latency and downtime feel the same from a frustrated browser. They are different incidents with different fixes — and different paging rules.

NKNabin Khair
What to do in the first two weeks after you turn monitoring on

What to do in the first two weeks after you turn monitoring on

The first fortnight of real monitoring is noisy on purpose. Here is how to tune it into something you trust — before the team learns to mute everything.

NKNabin Khair