All posts

UptimePricing

Uptime monitoring: watch the site, not one URL

Most uptime tools count one URL as one monitor, so watching a real site gets expensive fast. Here is how to watch every page that matters without paying per page — and without false alarms.

AxoWatch teamSeptember 24, 20265 min read

Uptime monitoring: watch the site, not one URL

Ask most uptime tools to watch your site and they will watch one address — usually the home page. The home page is the one page that almost never breaks. It is cached, it is static, and it is what everyone checks after a deploy.

What breaks is everything behind it: the cart, the booking form, the account page, the API route the checkout calls. To watch those you add more monitors — and since one monitor is one URL, the bill grows with every page.

One site, every page that matters

AxoWatch starts from the site, not the address. You type the domain; we read the sitemap and tick the main pages for you — the cart, the checkout, the pages people actually use. You adjust the list, and every page on it is checked around the clock.

The price follows the site, not the page count. Fifty pages of one site cost the same as five, because watching the whole site is the point.

Checked often, judged carefully

Every page is checked every 5 minutes by default — as often as once a minute, or as rarely as once a day. A check waits 10 seconds for an answer.

A single failed check doesn’t mean much. Networks drop packets, servers restart, a CDN edge has a bad minute. So one failure is “checking again”, not “down”:

  1. The first failed check flips the page to checking again.
  2. It is re-checked a minute later, and counts as down only after two failed checks in a row.
  3. While it is down, it is checked every minute, so the outage is measured to the minute.

You hear about the change of state — not every failed check. One message when it goes down, one when it is back, with how long the outage lasted. If several pages fail together, that is one message, not a flood.

More than “it answered”

A page that answers 200 with an error message inside is still broken. A check can ask for more:

  • The page contains a text — “Add to cart”, a price, your footer.
  • The page doesn’t contain a text — “Fatal error”, “Database connection failed”.
  • A specific status, when a 301 or 401 is the correct answer.
  • Headers or basic auth, for pages behind a login.

Pick the words carefully: a text your team changes every week will wake you at night for nothing. A text that only disappears when the page is really broken is worth its weight.

A reason in plain words

When a check fails, it says why: no answer in 10 seconds, connection refused, certificate isn’t valid, server answered 500. That is the first question anyone asks, and the answer is already in the alert.

The second question is “what broke it?”. If your app reports errors to AxoWatch, the errors that arrived during the outage are shown right next to it — the TypeError that took the cart down is one click away from the outage it caused.

Where to start

Add your domain and keep the pages we tick: the home page, the cart or sign-up, and the two or three pages your customers can’t do without. Leave the interval at 5 minutes. Add a “contains” check to the one page where a blank result would cost you money. That setup catches real outages within minutes — and stays quiet when nothing is wrong.

Try it on your site

Uptime Monitoring

Every page you care about, checked around the clock, including SSL certificate expiry.

Learn more

More from the blog

Let the guard take the night shift.

Add your site, show the guard what matters — and fix what breaks before your visitors give up.