What does website monitoring check?
Website monitoring sends a real HTTP(S) request to your URL on a fixed schedule and verifies that the response is what a visitor should get. In Uptime Tracker every standard HTTP(S) monitor checks four things on each run.
- Status code. By default any successful response passes. You can require a specific code, and on Starter and above you can accept a range such as 200–299.
- Page content. Keyword checks look for a substring that must be present (for example your footer text or a product name) or must be absent (for example
Database errororMaintenance mode). This catches the common case where a broken page still returns 200 OK. - TLS certificate. An expired, untrusted or wrong-hostname certificate fails the check, and the certificate expiry date is visible on the monitor. See SSL certificate monitoring for details.
- Response time. Each check records total time plus a breakdown into DNS lookup, TCP connect, TLS handshake and time to first byte.
You also control whether redirects are followed and how long to wait before treating a slow response as a timeout. Requests use GET by default. If you need POST requests, custom headers, an authentication token or JSON assertions, use an API monitor on the Starter plan instead.
Uptime monitoring is the broader term for the same idea applied to anything reachable over the network: websites, APIs, TCP ports, DNS records and scheduled jobs. Website monitoring is the most common starting point because it covers what customers actually see.
How Uptime Tracker avoids false alarms
Uptime Tracker only marks a website down after the failure is confirmed, so a single dropped packet or slow response does not wake you up. When a check fails, the monitor is re-checked, and it takes two consecutive failures before an incident opens and alerts are sent.
Recovery works the same way in reverse: a monitor needs two consecutive successful checks before it is marked up again. This prevents a flapping site from sending a stream of down-up-down notifications.
Two more rules keep your numbers honest:
- Probe and platform errors are not your downtime. If the problem is on our side, the result is not counted against your availability.
- Uncertain results show as unknown. When a result cannot be trusted, the monitor shows "unknown" instead of inventing an up or down state.
Checks currently run from one probe location. Additional independent probe regions are planned; once they exist, failures will also be confirmed from other regions before a monitor is marked down. Until then, the two-consecutive-failure rule is what filters out one-off network noise.
When an outage is confirmed, availability is backdated to the first failed check, so your uptime percentage reflects when the problem actually started rather than when it was confirmed. You can read more about how alerts are delivered on the alerts and notifications page.
How often should you check your website?
For most websites a 5-minute interval is enough to know about outages before customers start emailing you; revenue-critical sites benefit from 60-second or 30-second checks. Uptime Tracker supports intervals from 15 seconds to 3,600 seconds, limited by each plan's fastest allowed interval.
| Plan | Fastest interval | Checks per day per monitor |
|---|---|---|
| Free | 5 minutes | 288 |
| Starter | 60 seconds | 1,440 |
| Team | 30 seconds | 2,880 |
The interval sets the worst case for detection. With 5-minute checks an outage that starts right after a successful check is noticed at the next run, then confirmed by a re-check before you are alerted. With 30-second checks the same outage is caught within about a minute.
A practical approach many teams use:
- Homepage, checkout, login and API health endpoints on the fastest interval your plan allows.
- Marketing pages, blogs and documentation on 5 minutes.
- Internal tools that only matter during business hours on 5 to 15 minutes.
Faster checks also improve the resolution of your uptime history. If you want to see what a given availability target means in minutes of downtime, try the uptime calculator.
Response time and uptime reports
Every monitor keeps a time-weighted availability percentage and response time history, so you can prove uptime to customers and spot slowdowns before they become outages. Availability is calculated from how long the monitor was actually up, not from a simple count of passed checks, and planned maintenance windows are excluded.
The monitor detail view shows latency percentiles alongside the DNS, connect, TLS and time-to-first-byte breakdown. A slow DNS provider, an overloaded TLS terminator and a slow application server each look different in that breakdown, which shortens the time it takes to find the cause.
How far back you can look depends on your plan:
- Raw check results: 24 hours on Free, 72 hours on Starter, 7 days on Team.
- Aggregated uptime and latency history: 30 days on Free, 180 days on Starter, 395 days on Team.
- Incident history: 7 days on Free, 90 days on Starter, 365 days on Team.
Availability reports can be exported as CSV on every plan. Starter and Team add scheduled weekly or monthly email reports, which are useful for sending a regular summary to a manager or client. Team adds SLOs and error budgets so you can track a target such as 99.9% over a rolling period.
Starter and Team can also record deployment markers from CI. When an incident starts shortly after a deploy, the deploy is shown next to the incident as possibly related.
Set up website monitoring in a few minutes
You can have your first website monitored in under five minutes, with no credit card and no software to install.
- Sign in with your email address. Uptime Tracker is passwordless: you receive a one-time sign-in link or code, and a new address gets an account automatically.
- Name your workspace and choose your time zone. The time zone is used for maintenance windows, routing rules and reports.
- Add your first monitor: paste the URL, pick the check interval, and optionally add a keyword that must appear on the page.
- Choose where alerts go. Email works immediately; Slack, Discord, Telegram and signed webhooks are also available on Free.
- Optionally create a public status page and add the monitor as a component.
If you already track sites elsewhere, you can bring them in with a CSV import on any plan, or import an Uptime Kuma JSON backup. HTTP and keyword monitors, ports, ping, DNS, push and gRPC monitors are mapped automatically, and anything unsupported is listed so nothing disappears silently.
Prefer automation? Every plan includes the REST API with scoped tokens and the monctl command-line tool, so monitors can be created from scripts or CI. The help center has step-by-step guides for each check type.
What's included on each plan
Website monitoring with keyword and certificate checks is included on every plan, including Free; paid plans add faster intervals, more monitors and advanced request options.
| Free ($0) | Starter ($9/mo) | Team ($49/mo) | |
|---|---|---|---|
| Standard monitors | 2 | 10 | 50 |
| Fastest interval | 5 minutes | 60 seconds | 30 seconds |
| HTTP(S), keyword, redirects, timeouts | Yes | Yes | Yes |
| TLS certificate validation | Yes | Yes | Yes |
| Status code ranges | No | Yes | Yes |
| Custom methods, headers, body, JSON assertions | No | Yes | Yes |
| Raw check history | 24 hours | 72 hours | 7 days |
| Uptime and latency history | 30 days | 180 days | 395 days |
Annual billing costs 10 times the monthly price, which is two months free: $90 per year for Starter and $490 per year for Team. Prices are in USD and exclude tax.
New workspaces can try Team free for 14 days without a card. When the trial ends the workspace moves to Free automatically; excess monitors are paused rather than deleted. Full details are on the pricing page.
