Stop monitoring your homepage. Monitor the path that makes you money.

Here's a monitoring setup I see constantly: one check, pointed at https://example.com/, every minute, alerting on anything but a 200.

It's better than nothing. It's also aimed at nearly the least useful URL on the site.

My take: your homepage is the page least likely to break and least likely to tell you what's broken. If you only have budget, attention or alert capacity for a few checks, spend them on the path that makes you money.

Why the homepage is a bad canary

Think about what a modern homepage usually is:

• Heavily cached. Often served straight from a CDN edge. Your origin could be on fire and the homepage still returns a crisp 200.
• Mostly static. Marketing copy, images, maybe a pre-rendered page from a static site generator. It doesn't touch your database, your auth service or your payment provider.
• Changed by marketing, not engineering. When it does break, it's often a content issue rather than an outage.

Meanwhile, the things that actually fail in production (login, search, checkout, the API your mobile app calls) are dynamic, uncached and dependent on five other services. That's where outages live.

A homepage check answers "is the domain resolving, and is the CDN up?" That's worth knowing. It's just not the question your customers are asking when they can't pay you.

What to monitor instead

Start with one question: if this broke for an hour, what would it cost? Then monitor in that order.

For a typical SaaS, that's something like:

1. Login. If people can't sign in, nothing else matters.
2. The core action. Creating the thing your product creates: a project, a booking, a report.
3. Checkout or billing. Revenue, obviously.
4. The public API, if customers integrate with you.
5. The homepage. Yes, still. Last.

For a store: product page, add to cart, checkout start, payment confirmation page.

"But I can't monitor checkout without buying things"

You don't need a full end-to-end purchase every minute. There are cheaper layers:

Check an uncached dynamic endpoint. Most apps have a cheap endpoint that genuinely exercises the stack:

# bypass caches, and fail if the response doesn't contain what it should
curl -fsS -H 'Cache-Control: no-cache' \
  "https://example.com/api/products?limit=1&_=$(date +%s)" \
  | grep -q '"id"' || echo "products API broken"

Check for content, not just status codes. A login page that returns 200 with "Something went wrong" is down. Assert on a string that only appears when the page is healthy:

// check-login.mjs (Node 18+)
const res = await fetch("https://example.com/login", { redirect: "manual" });
const body = await res.text();
if (res.status !== 200 || !body.includes('name="password"')) {
  console.error("login page unhealthy", res.status);
  process.exit(1);
}

Run a real flow less often. A scripted browser test (Playwright, for example) that logs in with a test account and loads the dashboard every 5–10 minutes catches problems that single requests miss, like a JavaScript bundle that fails to load or an auth redirect loop.

// smoke-login.spec.js
import { test, expect } from "@playwright/test";
test("test user can log in", async ({ page }) => {
  await page.goto("https://example.com/login");
  await page.fill('input[name="email"]', process.env.SMOKE_USER);
  await page.fill('input[name="password"]', process.env.SMOKE_PASS);
  await page.click('button[type="submit"]');
  await expect(page.getByText("Dashboard")).toBeVisible({ timeout: 15000 });
});

Check payment dependencies directly. Most payment providers publish status pages. Watch them too, so "our checkout is failing" and "the provider is degraded" show up together.

Make the alert say what broke

A homepage alert tells you "something is wrong, somewhere". A checkout alert tells you "checkout is broken", which is the first line of your incident update and the first thing on-call needs to know.

Name your checks after the user journey, not the URL:

• ❌ https://example.com/api/v2/sessions
• ✅ Login: API session create

When the alert fires at 3 a.m., the second one needs no translation.

How many checks, and how often

A common worry is that monitoring user journeys means dozens of checks. In practice, a small product needs only a handful, at different intervals:

That's five checks, not fifty. Run the cheap ones often and the expensive ones rarely, and route them by severity: the homepage and the API page someone, while a failed login flow can open a ticket first and page only if it fails twice in a row.

The objections

"Homepage down means everything's down." Sometimes, when DNS or the CDN fails. Keep the homepage check for exactly that. Just don't treat its 200 as proof that everything else is up.

"More checks means more noise." Only if they're flaky. A few well-chosen checks on critical paths, with sensible retry and confirmation rules, are quieter than one check that's blind to most failures, because they don't let a real outage hide until customers report it.

"Synthetic flows are brittle." Browser tests can be, so run them less often, keep them short, and maintain them like code. A login smoke test is about 10 lines.

Where to start this week

1. List your top three money paths.
2. For each, find one URL or API call that fails when the path fails.
3. Add a check that asserts on content, not just status.
4. Rename your existing checks after user journeys.

You can do this with cron and curl, GitHub Actions, or a monitoring service like upordown.online. The tool matters much less than the choice of what you watch.

Related reading

• Your health check returns 200 while users get errors: 7 health check mistakes
• Our monitor said 100% uptime while the CDN served a 6-hour-old homepage
• Ping is not an uptime check: 5 ways ICMP lies about whether your site is up
• Your uptime alerts have never been tested. A 12-point checklist to prove they'll actually wake you

What's the one URL on your site that, if it broke, would hurt the most, and is it actually monitored? Tell me in the comments. I suspect plenty of answers will be "uh, no".