How to monitor website uptime, a practical setup guide for teams

Start with a list of the things a customer does, not the things your servers run. If a visitor cannot reach the homepage, sign in or pay, you are down from their point of view, even if every process on the host is green. Write the list in plain words and map each item to one check.

• Homepage. An HTTP(S) check on the main URL, expecting status 200 and a word that only appears when the page renders correctly.
• Login page. A keyword check on the sign in form, so a broken template or an error page with status 200 is caught.
• Checkout or signup. A check on the cart or pricing page, plus an API check on the endpoint that creates the order or account, where that is safe to call.
• API health endpoint. A dedicated route that touches the database and cache and returns a small JSON body you can assert on.
• SSL certificate. Expiry date and chain validity, checked daily.
• Domain registration. Expiry date at the registry, checked daily.
• Scheduled jobs. Backups, invoice runs, feed imports and queue workers, watched with heartbeat monitors.

Most teams end up with five to fifteen monitors per product. An agency multiplies that by the number of client sites, which is why grouping monitors per client matters from day one.

A server can return 200 with a maintenance banner, an empty product grid or a framework error page styled to look normal. A keyword check closes that gap. Pick a phrase that only renders when the page works, such as the label on the add to cart button or a footer string generated from the database. Avoid words that also appear in error templates. For APIs, assert on a field in the JSON body, for example that a status field equals ok and that a list is not empty. Our website monitoring and api monitoring pages describe these check types in detail.

The interval decides how fast you hear about a problem and how short an outage you can see at all. A check every five minutes can miss a four minute outage entirely. A check every minute will catch most real incidents within about two minutes once confirmation is counted. A 30 second interval halves that again.

On UptimePilot, Starter checks every minute and Team, Business and Enterprise check every 30 seconds. Intervals can be set per monitor, so you spend the fast checks where they matter.

A single probe location sees its own network problems as your outage. A routing issue between one data center and your host, a DNS resolver hiccup or a dropped packet can all produce one failed check. The fix is confirmation from a second place. UptimePilot checks from US East and EU Central, and a monitor is marked down only after a second region confirms the failure. That one rule removes most false alarms without hiding real outages, because a real outage fails from everywhere.

A check needs a timeout, and the default is rarely right for every page. If your checkout normally answers in 400 ms, a 30 second timeout means a badly degraded service still counts as up. A timeout of 5 to 10 seconds for pages and 3 to 5 seconds for a lightweight health endpoint is a reasonable start. Then look at real numbers after a week and tighten.

• Timeout per check. Treat a response slower than the timeout as a failure.
• Response time alert. Separate from up or down, alert when the p95 response time stays above a threshold for several checks in a row.
• Consecutive failures. With multi-region confirmation, one confirmed failure is usually enough to alert. Without it, require two or three.
• Redirects. Decide whether the check follows redirects. A homepage that suddenly redirects to a parking page should fail.

Response time trends are often the first sign of trouble. A database that runs out of connections tends to get slow before it fails. The website performance monitoring page explains percentiles and why p95 is a better alert signal than the average.

An alert that reaches the wrong channel is the same as no alert. Decide for each monitor group who gets told, how and when it escalates.

• Email for everything, as a record.
• Slack or Microsoft Teams for the team channel during working hours.
• SMS for the on call person, for production monitors only. SMS is the channel people read at night, so keep it for things worth waking up for.
• Webhook to your own incident tooling or chat bot.
• Escalation. If an alert is not acknowledged within a set number of minutes, UptimePilot alerts the next person in the chain.

Write the routing down in one sentence per group, such as "client sites alert the agency channel, checkout alerts the on call phone". If you cannot write that sentence, the routing is not finished. Our website downtime tracker page lists every alert channel and how escalation works.

Every alert should require a human decision. If people learn to ignore a channel, the one alert that matters gets ignored too. Remove monitors nobody acts on, raise thresholds on noisy staging checks and route low priority sites to email only.

Some outages are scheduled weeks in advance and still surprise people. A certificate that expires takes the whole site down for every browser at once. A domain that lapses can stop email and the website together, and recovering it can take days.

• SSL certificate monitoring checks expiry and the full chain, so a missing intermediate certificate is caught even when your own browser has it cached.
• Domain expiration monitoring reads the registration date and warns weeks ahead, which leaves time to fix a failed card on auto renewal.
• Cron job monitoring with heartbeats catches the backup that stopped running three weeks ago. The job calls a unique URL when it finishes, and UptimePilot alerts when the call does not arrive on schedule.

These failures produce no error on the site until the moment it breaks, which is exactly why they belong in the same tool as the uptime checks.

Planned work should not page anyone and should not count against your uptime number. Create a maintenance window for the deploy or migration, attach it to the affected monitors, and alerts pause for that period. Checks keep running in the background, so you still see when the service returns. Keep windows short and specific. A standing nightly window on every monitor hides real outages.

During an incident, support tickets that ask whether the site is down take time from the people fixing it. A status page answers that question once for everyone. Connect components to monitors, post short incident updates, announce scheduled maintenance and let customers subscribe to email updates. Host it on a subdomain such as status.yourdomain.com so it stays reachable when your main infrastructure does not.

Monitoring drifts. New pages launch, old endpoints move, a client leaves. A thirty minute monthly review keeps the setup honest.

• Read the uptime report for each group and note every incident longer than a few minutes.
• Check whether each incident alerted the right person and how long acknowledgement took.
• Remove monitors for retired pages and add monitors for new critical paths.
• Look at response time percentiles for slow drift.
• Confirm certificate and domain expiry dates are well in the future.
• Export the monthly SLA PDF for contracts or send the client report.

Teams on UptimePilot get uptime percent, response time percentiles and an incident log on every plan, a monthly SLA PDF from Team upward and white-label client reports from Business upward. See uptime monitoring pricing for the full comparison.