Uptime monitoring for client websites: what to check and how often

When a client's website goes down, the worst way to find out is from the client. For an agency, uptime monitoring is less about the graph and more about who knows first and what happens next. This guide covers which URLs to check on each client site, how often, and how to turn a failed check into an incident the client hears about from you.

What should you monitor on a client website?

The home page alone is not enough. A home page can return 200 OK from a cache while the login, checkout or API behind it is broken. Pick a small set of URLs that each prove something different works.

A sensible starting set for one client, using a fictional client, Northwind Logistics:

Incidents use four severity levels:

• Sev 1: Full outage
• Sev 2: Major feature broken
• Sev 3: Partial disruption (a workaround exists)
• Sev 4: Minor issue

Each check carries a pre-configured severity. Two consecutive failed pings raise an alarm at that level.

Five checks per client is plenty to start. An agency with 20 retained clients would run about 100 checks this way, which is easier to keep tidy than one check for every page.

A few points that save trouble later:

• Checks pass only on HTTP 200. Any other response, including a 301 or 308 redirect, registers as a failure, so a check can't currently be set up to expect a redirect. There's also no support yet for custom timeouts, request headers or authentication tokens on a check.
• Check through the real domain. Monitoring the server's IP address misses DNS and certificate problems.
• Use a health endpoint for APIs. Ask the developers for a lightweight URL that checks the database connection and returns 200 only when the app can serve requests.
• Don't monitor pages behind a login with a real account. Check the login page itself, not a page that needs a stored password.

Pings can also be triggered manually from the incident dashboard when you need an immediate check outside the schedule.

How often should uptime checks run?

Faster checks find outages sooner, but they also find more blips. The interval should match what an outage costs the client.

• Every 5 minutes: checkout, booking or payment pages, logins, client portals, APIs other systems depend on, and main marketing pages. This is the fastest interval currently available.
• Every 15 minutes: secondary pages that change rarely.
• Every 1 hour: brochure pages and anything non-critical.
• Manual ping: trigger a check on demand from the incident dashboard any time, independent of its schedule.

For comparison, UptimeRobot's free plan checks 50 monitors every 5 minutes and its paid plans go down to 60-second and 30-second intervals (UptimeRobot pricing, checked on 19 October 2026). UptimeRobot describes the free plan as good for hobby and non-profit projects, and its prices vary by region, so check the page for your own currency. It is a capable, focused monitoring tool, and if you need checks from several locations or every 15 seconds, a dedicated tool like this is the stronger choice.

How do you avoid false alarms?

A single failed check is often a network blip, a slow deploy or a cold cache. If every blip pages someone, people learn to ignore the alerts.

Timeouts, headers and authentication tokens for a check aren't configurable yet, so there's no tuning to do there. Two rules do the work:

1. Consecutive failures. Two consecutive failed pings raise an alarm at the endpoint's pre-configured severity level and open an incident. With a 5-minute interval, that's about 10 minutes.
2. Consecutive successes. Two consecutive successful HTTP 200 responses are required to clear the incident.

You can also trigger a manual ping from the incident dashboard to get an immediate read without waiting for the next scheduled check.

It also helps to record deployments. If a check fails two minutes after a release went out, that is your first lead. In Jonta, deployments reported by CI are recorded with their environment, version and tickets, and an incident can link to the deployment involved. See GitHub and deployments.

What should happen when a check fails?

Monitoring only helps if a failure turns into action. Write the steps down once and use them for every client:

1. Open an incident with a severity, for example Sev 2 for "the Northwind portal login is failing".
2. Name an incident commander who owns the response and the updates.
3. Post a client-visible update within minutes, even if it only says you are investigating.
4. Keep a timeline of what you found and changed.
5. Resolve and link the incident to the fix, for example ticket NW-142 and the deployment that shipped it.

In Jonta, two consecutive failed pings open the incident automatically at the check's configured severity, and two consecutive successful HTTP 200 responses resolve it. Pings can also be triggered manually from the incident dashboard. Incidents move through investigating, identified, monitoring and resolved. System admins are automatically emailed when an incident is raised, with an optional toggle to also notify the client; there's currently no way to route notifications to a specific individual. Promoting an incident into a project-board ticket is a manual step: incidents live in Jonta's internal incident area and aren't created as board tickets automatically. You choose whether each check is visible to the client, and 30 days of check history are kept. More on the incidents and uptime page.

One fair limitation: Jonta does not currently host a public status page for anonymous visitors. Updates reach clients through the client portal and email. If a client needs a public page for their own customers, Atlassian Statuspage is one option, with a Hobby plan at $29 a month (Statuspage pricing, checked on 19 October 2026).

What uptime checks don't catch

A status-code check tells you a page answered. It doesn't tell you everything is fine. Plan for these separately:

• Certificate expiry. Public TLS certificates are getting shorter lives: the maximum is 200 days for certificates issued from 15 March 2026, falling to 100 days from 15 March 2027 and 47 days from 15 March 2029 (DNSimple, SSL certificate validity changes). Automate renewal and check expiry dates with a separate tool or script.
• Domain renewal. Keep a list of client domains and renewal dates in your wiki, with an owner for each.
• Broken content. A page can return 200 with an empty product list. Checks only validate the status code, with no response-body or header validation, so content checks or end-to-end tests are needed to catch this.
• Slow pages. A timeout catches very slow responses, not gradual slowdowns.

How much does uptime monitoring cost for an agency?

Dedicated monitoring tools are often cheap on their own. The cost shows up when monitoring, incidents, client updates and tickets live in four different places and someone copies between them.

Jonta includes uptime monitoring and incident management on every plan. The Free plan covers up to 10 users, and Pro is £25 a month for your first 6 months, then £50 a month, for up to 50 users, or £405 for your first year, then £540 a year paid yearly (10% off). There are no per-user charges. See pricing for the full plan list.

A simple starting checklist

• Three to five checks per client, each proving something different works.
• Intervals of 5 minutes, 15 minutes or 1 hour depending on what an outage costs, plus manual pings from the incident dashboard.
• Checks pass only on HTTP 200, with no custom timeouts, headers or expected-code matching yet.
• Two consecutive failed pings before an incident opens; two consecutive 200 responses to resolve it.
• Four severity levels (Sev 1 to 4) set per check; escalating to a project-board ticket is still a manual step.
• A named incident commander and a first client update within minutes.
• Certificate and domain expiry tracked separately.

If you'd like to see uptime checks opening incidents and updating clients on a demo workspace with fictional data, book a demo or request a free workspace.

Questions people also ask

Written by the Jonta team.