Website uptime monitoring sends a request to your site on a fixed schedule and checks the answer. If the answer is wrong, slow or missing, you get an alert. That sounds simple, and it is. The value is in the details: how often you check, what counts as a failure, how a failure is confirmed, and how fast the right person hears about it.
Uptimecheck runs HTTP(S), ping and port checks every 1, 2, 5, 10, 15 or 30 minutes or every hour. Each check records the status code and the response time, so you see both outages and slow periods. If you want the background first, read what uptime monitoring is and why it matters.
Check types
- HTTP(S): request a URL with GET, POST or another method, send your own headers and body, and check the status code, a keyword or JSON fields in the response.
- Ping: confirm a host answers on the network, with the round-trip time.
- Port: check that a service such as a mail server or a database listener accepts connections.
For journeys that span several pages, such as logging in or checking out, use flow monitoring.
Why check every minute, and check twice
Downtime costs money by the minute. If your checkout answers 503 at 03:12 and nobody notices until the first support ticket, you have lost hours instead of minutes. Our guide to the cost of website downtime walks through the numbers.
Uptimecheck checks from Stockholm, Sweden, and confirms every failure with a second check before an incident opens. That cuts false alarms from a single dropped request or a brief network hiccup, while a real outage still reaches you within a minute or two. Our guide to reducing false alerts explains why that matters.
From failed check to fixed
- 03:12: the check to northwind.shop/checkout returns 503.
- 03:12: the second check fails too. An incident opens with the failing response and a screenshot of what visitors saw.
- 03:13: the on-call developer gets a push notification on their phone, and the team channel gets the details in Slack.
- 03:19: checks pass again. A recovery notice goes out with the total downtime.
Alerts go to email, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks and push notifications on your phone, on every plan. See alerts and notifications for routing and escalation, incident management for what happens after the alert, and pair monitoring with a status page so customers know what is happening without opening a ticket.
Response times, split into phases
Every HTTP check stores its response time, split into DNS, connect, TLS, server and download. A slow server phase points at your application; slow DNS or TLS points at infrastructure. Charts show the median, the 95th percentile and the average, so a slow tail does not hide behind a good average. Read more about website response time.
Set a limit such as 2,000 ms and you get a slow alert when three checks in a row are slower than that, and another when the site speeds up again. Slow time does not count as downtime.
The monitor’s page lists its latest checks. Three or more alike checks in a row fold into one line, such as “OK · 200 × 18” with the range of response times, and open to show each check. A failure never folds into a run of passes, and the second check that confirms a failure keeps its own line. If a monitor that isn’t paused hasn’t been checked for twice its interval, the page says “No recent data” with the time of the last check, so an old status never passes for a current one.
Check that the page really works
A page can answer 200 and still be broken: an empty product list, an error message, a maintenance page. Add response checks that must all pass:
- Expected status: codes or ranges, such as 200-299 or 200,301.
- Keyword: text the page must or must not contain, such as “Add to cart”.
- JSON and headers: for APIs, a field such as
$.statusequalsok, or a header that must be present.
HTTPS monitors also read the certificate and remind you before it expires. See SSL monitoring.
Set up your first monitor
Add the URL, pick the check type, set what counts as a valid response and choose which channels to alert. “Test request” shows the response before you save, and the first check runs straight away. Most teams start with three monitors: the homepage, the most important conversion page (checkout, sign-up or login) and the main API endpoint. Moving from UptimeRobot, Better Stack, Pingdom or StatusCake? Import your monitors with their settings and see every one before anything is created.
What counts as down
A check fails when the request times out, the connection is refused, the certificate is invalid, the status code is not what you expect or a response check does not hold. Uptime is the share of time without a confirmed outage, and maintenance windows do not count against it. Reports show uptime per monitor for any period against your SLA target, with CSV export.
Plans start at €9 per month billed yearly or €12 billed monthly, excl. VAT, with checks every minute on every plan. Compare monitors, status pages and history (1, 2 or 3 years) on the pricing page, look around the live demo without signing up, or start a 14-day free trial without a card.