Website uptime monitoring
Upcheck requests every website you own every five minutes, records how fast it answered, and tells the right people the moment one stops answering — by email, Slack, Discord, Teams, or webhook.
$10/month base · $1 per website · probed every 5 minutes
The first monitor most websites have is a customer
Downtime is rarely discovered by the people who can fix it. It is discovered by a customer replying to an invoice email, a colleague in a meeting, a dip on a chart somebody reads tomorrow. By the time the report travels to whoever owns the server, the outage has been running for the length of everyone's politeness — and the site was down the whole time for every visitor who did not bother to say so.
The fix is old and boring: request the site from outside, on a clock, and tell a human when the answer changes. What most teams actually run is either nothing, or a monitor so trigger-happy that it got muted in its first month. Both fail the same way — silently, at the worst moment.
The detection math: frequent enough that an outage is caught in minutes, confirmed enough that a passing blip never pages anyone.
So Upcheck splits the difference deliberately. Probes run every five minutes, but no human hears about a failure until a second probe confirms it — because the expensive failure mode of uptime monitoring is not the ten minutes of detection lag, it is the team that stopped believing its own alerts. A 4xx answer is filed as a warning rather than an outage for the same reason: a root URL suddenly answering 404 deserves attention, but it is not the site being down, and treating it as one teaches everyone to ignore the channel.
Monitoring website uptime in three steps
- 01
Add the websites you own
Upcheck requests each one over HTTPS the way a visitor's browser would — a real GET of the page, following redirects, with caching disabled so a stale 200 can never hide a live outage. No agent, no status-page pixel, no code on your side.
- 02
Every site is probed every 5 minutes
Each probe records the HTTP status and the response time in milliseconds, so you see a site getting slower before you see it down. You can also run a check on demand from the dashboard, which probes the site immediately.
- 03
Outages are confirmed, then alerted
One failed probe starts the clock; a second, five minutes later, confirms the outage and fires your uptime rules — to email, Slack, Discord, Teams, or webhook. When the site answers again, a recovery alert closes the loop.
Up or down is a verdict, not the evidence
A green dot tells you the site answered. It does not tell you the site answered in four seconds instead of eighty milliseconds, or that every request has been quietly redirecting to a staging host since Tuesday. Upcheck keeps the evidence behind every verdict — status, timing, and where redirects actually landed — so the question after "is it down" has an answer too.
History is written on every status change, with a heartbeat row every six hours in between, and kept for 90 days. That is enough to answer "how long was it down" and "has this happened before" without turning every probe into a database row.
Every state an uptime check can be in
Down is not the only interesting answer. The states are deliberately few, and the line between "worth a look" and "worth a page" is drawn where your sleep is.
- OK
The site answered with a success or a redirect inside 10 seconds. The response time is on the board, so a site drifting from 80ms to 4 seconds is visible long before it stops answering.
- Warning
The site answered, but with a client error — a 403, 404, or 401 at the root. Alive but answering wrongly: worth a look in the morning, not worth waking anyone at 3am.
- Failing
A server error, or no answer at all within 10 seconds — a timeout, a refused connection, a failed handshake. One failing probe starts the clock; the second confirms the outage and fires your rules.
- Checking
Just added. The first probe runs the moment a website lands in the workspace, so a new site has a real verdict in seconds, not at the top of the next interval.
One alert per outage, not one per probe
An uptime rule fires when an outage is confirmed and, if you add the recovery trigger, again when the site answers — with nothing in between unless you ask for it. Set the cadence to once and that means once per incident: a site that goes down on Tuesday and again on Friday alerts both times, but a six-hour outage does not fill the channel with repetition. Prefer a drumbeat while something stays down? Set the rule to hourly instead.
Rules cover the whole workspace by default, or you can scope one to specific websites — so the payments API pages the on-call phone while the docs site posts to a channel. The outage alert names what the site answered with and how long it has been failing; the recovery alert closes the incident with what it answered with when it came back.
Delivery goes to email, Slack, Discord, Microsoft Teams, or your own webhook, where an outage arrives as a structured uptime.alert event your tooling can route apart from an expiring certificate. Email recipients live in named lists you define once and point any rule at, so the on-call rotation changing does not mean rewriting rules.
What to look for in website monitoring tools
Uptime monitoring is the oldest product category on this page, which means it is also the most padded. If knowing about outages before customers do is the thing you are actually buying, these are the capabilities that decide whether it works.
- 01
Confirmation before paging
A monitor that alerts on every blip gets muted inside a month, and a muted monitor is worse than none. Failure should be confirmed by a second probe before a human hears about it.
- 02
A real request, not a ping
ICMP proves the box is powered on. Only an actual HTTP request — status code read, redirects followed — proves the site a visitor gets is the one you meant to serve.
- 03
Recovery alerts
Half the value of an outage alert is the all-clear. Without one, someone refreshes the site every two minutes until it loads — which is monitoring by hand, again.
- 04
Response time, not just up/down
Most outages announce themselves as latency first. A tool that records milliseconds per probe shows the drift; a binary up/down shows nothing until it is too late.
- 05
Alerts where the team already is
An email to a shared inbox nobody reads is not an alert. Look for Slack, Discord, Teams, and a plain webhook so an outage can open an incident in your own tooling.
- 06
The slow failures, beside the fast one
Downtime is the fastest failure a website has, not the only one. The certificate, the DNS records, and the domain registration all take a site down on their own schedules.
Four checks, one price
$10 per month for the workspace, plus $1 per website per month — and the dollar covers everything Upcheck watches on that website: uptime every 5 minutes, the SSL certificate every 12 hours, DNS every 6, and the domain registration daily. The per-website charge is metered daily, so adding a website mid-cycle costs only the days it was tracked. Every feature on this page is included at every size; there is no tier that withholds Slack, or webhooks, or history. A workspace can track up to 500 websites.
The slower failures on the same websites have their own pages — see SSL certificate expiration monitoring and DNS monitoring.
Frequently asked questions
What is website uptime monitoring?
Website uptime monitoring is the practice of automatically requesting a website at a fixed interval, from outside its own infrastructure, to establish that it still answers — and telling a responsible person promptly when it stops. A monitor records the HTTP status and response time of every probe, separates a real outage from a passing blip, and delivers the alert somewhere the team actually looks, so downtime lasts minutes instead of being discovered in the morning.
How often does Upcheck check my website?
Every website is requested over HTTPS every 5 minutes, around the clock. An outage is confirmed by a second failed probe before anyone is alerted, so the worst case from a site going down to a confirmed alert in your channel is about ten minutes, and the typical case is closer to five. You can also run a check on demand from the dashboard, which probes the site immediately.
What does Upcheck count as down?
A server error — any 5xx response — or no response at all within 10 seconds: a timeout, a refused connection, a failed TLS handshake, a name that no longer resolves. A 4xx response is reported as a warning instead, because a site answering 403 or 404 at its root is alive but answering wrongly, which deserves a look rather than a page. Redirects are followed, so a site that moved to www still counts as up. Probes are made over HTTPS, so a site with nothing listening on port 443 reports as failing.
How does Upcheck avoid false alarms?
Two ways. Each probe is a real GET of the page with caching disabled, so a stale cached 200 can never mask a live outage. And no alert fires on a single failed probe: a website is only confirmed down after two consecutive failures, five minutes apart. A monitor that cries wolf gets muted, and a muted monitor is worse than none — so the design errs toward paging you once, correctly.
Does Upcheck tell me when the site comes back up?
Yes. Add a recovery trigger to an uptime rule and Upcheck sends the all-clear the moment a confirmed-down website passes a probe again, including the status and response time it answered with. Recovery alerts only follow confirmed outages — a blip that never paged anyone does not generate a recovery message either.
Where can Upcheck send downtime alerts?
Email, Slack, Discord, Microsoft Teams, and your own webhook endpoint. Email alerts go to reusable recipient lists you name and point rules at, so changing who is on call does not mean editing every rule. The webhook payload is a structured JSON event — uptime.alert — carrying the domain, status, and message, so your own tooling can route an outage differently from an expiring certificate.
Does Upcheck monitor from multiple locations?
Each probe is a single request from Cloudflare's edge network, not a quorum across regions. That is a deliberate trade: the question a 5-minute cadence answers is "did the site stop answering", and confirmation comes from two probes separated in time rather than in geography. If you need per-continent latency measurement or regional outage detection, you want a multi-region tool on top of this one.
Can I monitor website uptime for free?
Checking once is free — Upcheck's own website down checker tells you right now whether a site is answering, no signup. The watching is the paid part: re-running the check every 5 minutes, confirming failures, and telling a human costs $10 per month for the workspace plus $1 per website per month, and that dollar covers all four checks on the website: uptime every 5 minutes, the SSL certificate every 12 hours, DNS every 6, and the domain registration daily.
Know before the customer does.
Add the websites you own, decide who hears about an outage, and let the probes run.