How to monitor server uptime: checks, tools and alerts

To monitor server uptime, run automated checks from outside the server (ping, TCP port or HTTP requests from several locations), collect the server's own health signals with an agent, and alert only when several locations fail in a row. Then record every outage so you can calculate availability against your SLA each month.

Key takeaways

• External synthetic checks answer "can users reach it?"; internal agents answer "why is it down?". You need both.
• Check from at least three locations and alert on consecutive failures to avoid false alarms from one bad network path. Microsoft recommends at least five test locations for Azure availability tests.
• Test what users use: an HTTPS request that checks the status code and page content beats a ping.
• 99.9% availability still allows about 43.8 minutes of downtime a month. Know what your target allows before you set alert thresholds.
• Exclude agreed maintenance windows consistently, and report uptime from the same data every month.

What is server uptime monitoring?

Server uptime monitoring is the continuous checking of whether a server and the services on it are reachable and responding correctly. It produces two things: alerts when something goes down, and a history you can turn into an availability percentage.

Uptime and availability are related but not identical. A server can be powered on (high uptime) while its web service returns errors (low availability). For most businesses the number that matters is service availability, as seen by users.

How much downtime does each uptime target allow?

Availability is (total time − downtime) ÷ total time. The table converts common targets into allowed downtime, using an average month of 730 hours.

A tight target changes how you monitor. At 99.99% a five-minute check interval cannot even detect every breach, so you need checks every minute or faster and an on-call response measured in minutes. Google's SRE book chapter on embracing risk explains why each extra nine costs more and why the target should follow business need.

Which checks should you run?

External (synthetic) checks

• ICMP ping: shows the host answers on the network. Cheap, but many firewalls block it, and a host can answer ping while its applications are down.
• TCP port checks: confirm a service is listening, for example 443 for HTTPS, 3389 for RDP or 5432 for PostgreSQL.
• HTTP(S) checks: request a URL, check the status code, response time and a piece of expected content. Use a dedicated health endpoint that also tests the database connection.
• TLS certificate checks: warn before a certificate expires. An expired certificate is an outage for users even when the server is healthy.
• DNS checks: confirm the name resolves to the right address.

Internal (agent-based) signals

• Heartbeat: the agent reports every minute; a missing heartbeat means the host or agent is down.
• System uptime counter: shows unplanned reboots. On Linux use uptime or last reboot; on Windows, event ID 6008 in the System log records an unexpected shutdown.
• Resource metrics: CPU, memory, disk space and disk latency. Full disks and memory exhaustion are common causes of "up but not working".
• Service and process state: is the web server, database or scheduled job running?

For Windows hosts, our guide on how to monitor Windows Server performance lists the counters worth collecting.

Which tools can monitor server uptime?

The choice matters less than the setup. A self-hosted tool also needs monitoring: if your only monitoring server sits in the same rack as the servers it watches, a power failure takes out both. Run at least one external check from a different network or a cloud service.

How to set up uptime alerts without false alarms

1. Use several locations. Microsoft recommends at least five test locations for Azure availability tests and an alert threshold of the number of locations minus two, for example three failing out of five.
2. Require consecutive failures. Azure's retry option reports a failure only after three successive attempts fail; Microsoft notes that about 80% of failures disappear on retry.
3. Set severity by impact. A production customer portal pages the on-call engineer; a test server sends a ticket.
4. Route alerts to people who can act, with escalation if nobody acknowledges within a set time.
5. Silence planned maintenance in the monitoring tool rather than ignoring alerts by habit.
6. Alert on recovery too, so the team knows when the incident is over.

Google's SRE guidance on monitoring distributed systems adds a useful rule: every page should be urgent, actionable and need a human. Anything else belongs in a ticket or a dashboard.

How to report uptime against an SLA

• Define what counts as down, for example "health endpoint fails from three of five locations for two consecutive checks".
• Agree which maintenance windows are excluded, and record them in the tool.
• Calculate monthly availability from check results, not from memory or ticket notes.
• Keep an outage log with start, end, cause and fix. Patterns, such as outages after every patch night, show where to invest.
• Compare your number with what your cloud provider commits to. For example, the Amazon Compute SLA commits to 99.99% monthly uptime for EC2 deployed across multiple availability zones in a region, but only 99.5% for a single EC2 instance. Your application's availability can never exceed what its weakest dependency delivers.

Monitoring tells you about outages; redundancy prevents them. Run critical workloads on more than one server or availability zone behind a load balancer, so a single failure does not take the service down. WorkBuster, a SaaS recruitment platform, runs on EC2 behind an Application Load Balancer with multi-AZ MySQL RDS, an auto-scaling group and CloudWatch dashboards and alarms; the WorkBuster case study shows the full setup.

How Opsio helps

Opsio runs 24/7 monitoring and incident response for servers and cloud workloads on AWS, Azure and Google Cloud. We set up checks, alert routing and monthly availability reports, and our engineers act on the alerts. See our cloud monitoring and support services, remote infrastructure monitoring and Prometheus and Grafana observability pages.

Frequently asked questions

How do I check how long a server has been up?

On Linux, run uptime or last reboot. On Windows, open Task Manager's Performance tab, run systeminfo and read "System Boot Time", or check the System event log. These show time since the last boot, not whether services were available.

How often should uptime checks run?

Every one to five minutes for most production services. Match the interval to your target: at 99.99% you only have about 4.4 minutes of downtime a month, so a five-minute interval is too slow to measure it.

Is ping enough to monitor server uptime?

No. Ping only proves the network stack responds. Add a TCP or HTTPS check against the service users depend on, ideally with a content match, plus agent-based checks on the server itself.

What is a good uptime percentage for a server?

For business applications 99.9% is a common target; customer-facing services often aim for 99.95% or higher. Higher targets need redundancy: AWS, for example, commits to only 99.5% for a single EC2 instance but 99.99% for EC2 spread across availability zones.

Can I monitor uptime for free?

Yes. Open-source tools such as Prometheus with blackbox_exporter, Zabbix or Nagios cost nothing to license, though you pay in hosting and maintenance time. Cloud providers' native checks are low-cost for small numbers of endpoints.

Related reading

• What Is Cloud Monitoring
• What Is Real-Time Monitoring for Servers and Applications?
• How to Monitor Windows Server Performance? Tools and Metrics