Skip to content
UptimePilot

How uptime monitoring works, from a URL to a confirmed alert

Uptime monitoring is simple in principle. A service outside your network requests your site, API or server on a schedule, judges the answer and tells the right people when something is wrong. The details decide whether you hear about a real outage in a minute or get woken up by a false alarm. Here is exactly what UptimePilot does at each step.

Run an uptime check

The check passes when this exact text appears on the page.

No card required to run a check. Your monitor data stays yours.

See pricing
Architect measuring a floor plan with a steel scale ruler at a bright table
  1. 01

    Add a URL or a host

    You start with what you want to watch: a page URL, an API endpoint, a hostname or IP for ping and port checks, or a domain for certificate and registration expiry. For a cron job or background worker, UptimePilot creates a unique heartbeat URL instead, and you add one call to it at the end of the job. You set the interval (every minute on Starter, every 30 seconds on Team and above), the timeout and the accepted status codes. Most teams start with their homepage, login or checkout page, main API health endpoint and certificate, which covers the most common outages in a few minutes of setup.

  2. 02

    Choose regions and checks

    Each monitor runs from a main region, US East or EU Central, and the other region stands by to confirm failures. You choose the check type: plain HTTP(S), a keyword that must be present or absent, an API request with assertions on the JSON response, ping, TCP port, SSL certificate, domain expiry or heartbeat. A keyword check matters more than it looks. Many outages return status 200 with an error page, an empty template or a maintenance notice, and only a content check catches them. The uptime monitoring features page lists every option.

  3. 03

    Pick who gets alerted

    You decide who hears about an outage and how. Alerts go by email, SMS, Slack, Microsoft Teams or webhook, and every channel is included in every plan. An escalation rule moves the alert to the next person if nobody acknowledges it within the minutes you choose. Maintenance windows pause alerts while you deploy, so scheduled work does not page anyone. More on alert setups on the website downtime tracker page.

  4. 04

    Publish a status page

    Finally, you connect monitors to components on a status page. When a monitor goes down, the component shows it, and you post incident updates in plain language as you work. Subscribers receive those updates by email. A clear status page is the fastest way to stop "is it down?" tickets during an incident.

What happens during a single check

Every HTTP check goes through the same stages, and UptimePilot times each one. The timing breakdown is what turns "the site is slow" into "TLS takes 900 ms from EU Central".

  • DNS lookup resolves your hostname to an IP address. A failure here usually means a misconfigured record, an expired domain or a DNS provider problem.
  • TCP connect opens a connection to the server. Slow connects point to network distance or an overloaded load balancer, and refused connections mean nothing listens on the port.
  • TLS handshake negotiates encryption and checks the certificate. An expired certificate, an incomplete chain or a hostname mismatch fails here, before any content is sent.
  • First byte measures how long the server takes to start answering. This is mostly your application and database time, and it is where slow queries and cold caches show up.
  • Content check reads the response, compares the status code with the accepted range and looks for your keyword or evaluates your JSON assertions.

If any stage fails or the total time passes your timeout, the check counts as failed. Response times from successful checks build the p50, p95 and p99 percentiles shown on website performance monitoring.

Confirmation from a second region

A single failed request is not proof of an outage. Packets get dropped on one route, a resolver times out, a transit link has a bad minute. When a check fails, UptimePilot repeats it from the second region right away. Only if that check fails too is the monitor marked down. This is why you get fewer false alarms without slowing down detection of real outages, which still reach you within about one interval.

How an alert travels and escalates

Once a monitor is confirmed down, UptimePilot opens an incident and sends alerts to the channels on the monitor's rule. The alert names the monitor, the failing stage, the status code or error, and the regions that saw it. If the rule has escalation and nobody acknowledges within the set time, the next person or channel is alerted, and so on down the list. When checks pass again, a recovery alert goes out with the outage duration, and the incident closes on its own.

From incident to status page

If the monitor is linked to a status page component, the component changes status as soon as the incident opens. You add updates as you learn more, for example "We are investigating", "The cause is identified" and "Fixed, monitoring", and subscribers receive each update by email. After recovery, the incident stays in the page history so customers can see how you handled it.

The monthly report

At the end of each month, every monitor has an uptime percent, response time percentiles and an incident log with start, end and duration. Team and higher produce a monthly SLA report as PDF, and Business adds white-label client reports for agencies. Read more on the uptime monitoring service page. To see which plan fits your monitors, check uptime monitoring pricing.

01

How often does UptimePilot check my site?

Every minute on Starter and every 30 seconds on Team, Business and Enterprise.

02

Why does a second region confirm a failure?

Because a single failed request often comes from one bad network route, not from your server. Confirmation from a second region filters those out, so alerts point to real outages.

03

What does a heartbeat monitor do differently?

It waits for your job to call it. If the call does not arrive within the expected schedule plus a grace period, UptimePilot alerts you. It catches jobs that silently stop, which a normal HTTP check cannot see. See cron job monitoring.

04

Do checks put load on my server?

Very little. One request per interval per monitor is a small fraction of normal traffic. UptimePilot does not run load tests.

05

Can I see a real check before signing up?

Yes. The website uptime test runs a real check of a public URL and shows the timing breakdown. No card is required to run a check.

Set up your first monitor in about a minute

Add a URL, choose regions and checks, pick who gets alerted and publish a status page.