Is one uptime monitor on my homepage enough?

No — a homepage monitor tests one rendering path on one route. It misses a broken API that your app's pages call, a dead background job, an expiring certificate on a subdomain, a database that's down while a cached homepage still serves, and a checkout flow returning errors. One monitor is vastly better than zero, but the useful floor for a real product is about six: the homepage, a health endpoint with dependency checks, your most critical API or flow, one monitor per scheduled job that matters, and one per third-party dependency you'd take action on.

Should I monitor every page of my website?

No. Pages that share a failure domain — same origin, same rendering path, same data dependencies — go down together, so monitoring fifty of them buys you fifty duplicate alerts and no extra detection. Monitor one representative page per rendering class (server-rendered, static/CDN-served, cached) plus any page with a genuinely distinct dependency, like a checkout page that's the only thing touching your payment provider. Coverage comes from spanning failure domains, not from URL count.

How many monitors do I need for microservices?

Roughly one to two per service — a health endpoint that checks the service's own hard dependencies, plus its critical public route through the gateway if it has one — and monitors on the shared entry points (gateway, auth). Resist monitoring every internal endpoint of every service: the service's health check should aggregate its internals, and the per-endpoint failure modes usually share a domain with it. A ten-service system lands around 15–25 monitors, not 100.

When is it worth splitting one monitor into several?

Split when the pieces differ in one of three ways: failure mode (a static page and an SSR page fail on different axes, and the pattern of which is down is diagnostic), audience (alerts for the marketing site go to a different channel than alerts for the API), or commitment (a route covered by a customer SLA deserves its own monitor and its own reporting history). If two monitors would always fire together, page the same people, and mean the same thing, they should be one monitor.

How many monitors is too many?

You've overshot when one outage produces a page of simultaneous alerts, when monitors exist that no one would act on, or when people start ignoring the alert channel — monitor count is an alert-fatigue input, and fatigue defeats the whole system. The marginal monitor should add a failure domain you couldn't see before or split an alert toward a different audience. If it does neither, it's noise with a green dot.

How Many Uptime Monitors Do You Need?

Short answer: most small products need six to twelve monitors — more than the single homepage check most people start with, far fewer than the one-per-URL sprawl monitoring vendors are happy to sell you. The right number isn't a function of how many pages you have. It's a function of how many ways your system can fail.

That's the whole sizing rule: count failure domains, not URLs. This post turns it into a concrete starter set, the three legitimate reasons to split a monitor into several, the signs you've overshot, and typical counts by team type — including how they map onto monitor caps (CronAlert's free plan is 25, which comfortably fits everything below the agency tier).

The sizing rule: failure domains, not URLs

A failure domain is a set of things that break together. Fifty blog posts on the same origin, served by the same CDN from the same build, are one failure domain — if one is down, they're all down, and fifty monitors would just fire fifty times. Meanwhile a single "the app" can hide six failure domains: the static marketing pages, the server-rendered app, the API, the database behind it, the nightly billing job, and the third-party payment provider. One homepage monitor covers exactly one of those six.

So the method is: list the ways your system fails independently, then place one monitor per way. Both errors — undermonitoring and overmonitoring — are failures of the same mapping. A monitor that shares a failure domain with another is redundant; a failure domain with no monitor is a blind spot; and most setups have both at once.

The starter set (about six monitors)

1. Your main page. The front door, checked from outside — this also covers DNS and the TLS certificate on your apex domain (CronAlert checks certificate expiry on HTTP monitors automatically).
2. A health endpoint with dependency checks. One /api/health route that verifies the database and other hard dependencies converts several internal failure domains into one honest status code. This is the highest-leverage monitor on the list.
3. Your most critical API or flow. The endpoint whose failure costs money — login, checkout, the API your customers integrate. If your app renders client-side, this matters double, because the page shell will 200 while the API burns.
4. One page per rendering class, if you have more than one. Static and server-rendered pages fail on different axes; the pair is a built-in diagnostic. (Skip if everything renders one way.)
5. One heartbeat per scheduled job that matters. The backup, the billing run, the sync — cron jobs fail silently by default and no HTTP monitor can see them. Heartbeats are on Pro ($5/mo); this is usually the reason to upgrade.
6. One per third-party dependency you'd act on. Stripe, your email provider, your auth provider — monitored through your own integration point where possible. "Act on" is the filter: if the response to it failing is only "wait," a status-page subscription beats a monitor.

A side project trims this to three or four. A funded startup grows each line: more flows, more jobs, more dependencies. But the categories don't change, and notice what never appears: "every page."

Three legitimate reasons to split one monitor into several

Different failure modes. If two things can break independently, split them — the split is what makes the alert diagnostic ("SSR down, static up" locates the problem before you've opened a laptop).
Different audiences. If the marketing site pages a different channel than the API, they need separate monitors so routing can differ. Agencies live by this: each client's monitors alert toward that client's channel.
Different commitments. A route covered by a customer SLA gets its own monitor so its uptime history is its own report, not an average across unrelated routes.

The inverse test: if two monitors would always fire together, page the same people, and mean the same thing — merge them.

Signs you've overshot

One outage, a wall of alerts. Ten monitors inside one failure domain turn every incident into a notification storm that buries the diagnostic signal.
Monitors nobody would act on. If it went red and the honest response is a shrug, it shouldn't page anyone.
The channel is being ignored. The terminal symptom. Monitor count is an input to alert fatigue, and fatigue quietly zeroes the value of everything else. (The fix is pruning and routing, not more monitors — and an occasional fire drill to prove the alerts that remain still land.)

The marginal-monitor test: does it add a failure domain you couldn't see, or split an alert toward a different audience? If neither, it's decoration.

Typical counts by team type

Setup	Typical count	What's in it
Side project / static site	3–6	Main page, one more rendering class or form endpoint, a cron heartbeat, maybe a dependency
SaaS startup	8–15	The starter set, grown: 2–3 flows, 2–4 job heartbeats, 2–3 dependencies, staging health
Microservices team	~1–2 per service + entry points	Health endpoint per service, gateway and auth, critical public routes — details here
Agency	3–5 per client site	Site, contact/checkout flow, SSL/DNS, client-routed alerts — details here

Mapped to plans: the first two rows fit CronAlert's free tier (25 monitors) with room to spare — the usual upgrade trigger is wanting heartbeats or 1-minute checks rather than monitor count. Agencies and microservices teams land on Pro (100 monitors, $5/mo) or Team for the seat count and per-client status pages.

Frequently asked questions

Is one homepage monitor enough?

It's one failure domain out of the half-dozen a real product has. Better than nothing; the useful floor is about six.

Should I monitor every page?

No — one representative per rendering class plus pages with genuinely distinct dependencies. Same-domain pages fail together.

How many for microservices?

One to two per service plus the shared entry points — around 15–25 for a ten-service system.

When do I split a monitor?

Different failure mode, different audience, or different SLA. Otherwise merge.

How many is too many?

When one outage floods the channel, or monitors exist that nobody would act on. Fatigue defeats coverage.

Start with six, grow by failure domain

Sizing monitoring is a mapping exercise, not a shopping decision: list the ways your system fails independently, put one monitor on each, and stop. For most products that's six to twelve — CronAlert's free plan covers 25, so the constraint is your failure-domain list, not the bill. Set up the starter six this afternoon, and add number seven the next time you build something that can break alone.