Uptime Monitoring
Real-time availability tracking for every service you run.
Uptime monitoring continuously checks whether your web services, servers, and endpoints are reachable and responding. When something goes offline, your team is alerted immediately — not after a customer calls to report the problem. Historical uptime data gives you the documentation needed to meet SLA commitments and demonstrate reliability to clients.
The cost of discovering outages late
Without monitoring, the typical way an outage is discovered is a support ticket, a social media post, or a phone call from a client. By that point, the service has been down for minutes or hours. The time between when a failure occurs and when your team begins responding directly determines how long users are impacted. Uptime monitoring eliminates that gap by alerting you within seconds of a failure being detected.
Not every outage looks the same from the outside. A server can be completely unreachable, or it can be up but returning 500 errors, or slow enough that requests start timing out before a response ever arrives. Each of these needs a check that actually looks at the response — a ping-only check would call a server returning 500 errors on every request "up," even though every real visitor is seeing a broken page.
Uptime data also has value beyond incident response. An accurate availability record is essential for demonstrating compliance with SLA commitments, identifying patterns of recurring instability, and making the case for infrastructure investment when repeated outages affect the same component.
What NetTests uptime monitoring checks
NetTests requests each monitored URL on a schedule as short as one minute, checking that the response comes back with an expected HTTP status code within your configured timeout. A slow response that eventually times out is treated as a failure the same way an unreachable server is — both mean a real visitor wouldn't have gotten a working page.
Every check is logged, building the historical record behind an uptime percentage that actually means something: not an estimate, but a calculation from every real check run in the period. Every incident — start time, end time, and total duration — is recorded automatically, giving you a ready-made audit trail rather than something reconstructed from memory after the fact.
Planned maintenance windows suppress alerts for the duration you set, so expected downtime doesn't page anyone or count against your uptime percentage. Alerts for real incidents reach your team through email, Slack, Microsoft Teams, or SMS the moment a check fails.
Key features
HTTP and HTTPS monitoring
Check web endpoints for correct status codes and response content at configurable intervals.
Instant alerting
Receive notifications immediately when a check fails — not after multiple missed checks or a delay.
Uptime percentage reporting
Calculate availability percentages over any time range for SLA reporting and client communication.
Incident history
Every outage is recorded with start time, end time, and duration — a complete audit trail of availability events.
Maintenance windows
Suppress alerts during planned maintenance so expected downtime doesn't generate noise.
Multi-site monitoring
Track availability for dozens of websites and services from a single dashboard.
Checks as often as every minute
Short check intervals catch brief outages that longer-interval monitoring would simply miss between runs.
Multi-channel alerts
Reach your team through email, Slack, Microsoft Teams, or SMS the moment a check fails.
What you'll see
A live look at availability across your monitored services, and the alert that fires the moment one goes down.
Not ready to commit?
Try the free HTTP Quick Check first. Confirm a URL returns a healthy response right now, then set up continuous monitoring so you're alerted the moment that changes.
Try the free tool →Free availability tools
Frequently asked questions
How is uptime percentage actually calculated?
From real check results over the period: the fraction of scheduled checks that returned a healthy response, not an estimate or a theoretical figure. A shorter check interval produces a more precise percentage, since a brief outage between two checks a minute apart is far more likely to actually get caught than one between checks an hour apart.
What counts as "down" — just unreachable, or also errors?
Both. A connection that times out or refuses counts as down, and so does a response that comes back with an unexpected status code (a 500 error, for example) — a server that's technically responding but broken is just as much an outage to a real visitor as one that isn't responding at all.
How often should checks run?
Depends on how quickly you need to know. A one-minute interval catches brief outages that a five- or ten-minute interval would simply miss between runs, at the cost of more check volume. Customer-facing production services generally warrant the shortest interval available; lower-traffic internal tools can usually tolerate a longer one.
Can maintenance windows prevent false alerts?
Yes — set a maintenance window for planned downtime and checks during that period won't page anyone or count against your uptime percentage. This keeps the historical record accurate: a deliberate deploy-related restart looks different from an unplanned outage, and your SLA reporting should reflect that difference.
Is uptime monitoring enough on its own, or do I need other checks too?
Uptime monitoring answers "is it up," which is necessary but not sufficient — a site can be up and still slow, insecure, or serving expired content. Most teams pair it with performance monitoring for response-time trends and, where relevant, SSL or DNS monitoring for the infrastructure underneath.
Start monitoring uptime now
Set up your first uptime monitor in minutes. NetTests checks continuously and alerts your team immediately when something goes offline.
Start monitoring free →