Learn
What is uptime monitoring?
Uptime monitoring is the practice of checking a website, API or server from outside your own infrastructure at a regular interval, recording whether each check succeeded and how long it took, and alerting someone when checks start failing. It tells you a service is unavailable before customers do and produces the history behind an uptime percentage.
How does uptime monitoring work?
An uptime monitor is a small program running somewhere other than your servers. At a fixed interval, typically between ten seconds and five minutes, it makes a request to the thing you care about: it loads a page, calls an API, opens a TCP connection or resolves a DNS name. It then decides whether the response was healthy, for example a 200 status code within a timeout, and stores the result together with the response time and the location it checked from.
When a check fails, the monitor does not usually alert straight away. It retries, often from a different location, and only opens an incident once the failure has been seen enough times to rule out a one-off network blip. Alerts then go to whichever channels the team watches: email, chat tools, a paging service or a webhook. When a later check succeeds, the monitor sends a recovery message with the total length of the outage and closes the incident.
Over weeks and months those individual results become the data behind uptime percentages, response-time graphs, incident history and status pages.
What can you monitor?
The word uptime suggests a single on/off state, but modern monitors cover several kinds of failure. The most common check types are:
- HTTP(S): request a URL and verify the status code, optionally with custom headers, authentication and a response-time limit.
- Keyword: load a page and confirm that a word or phrase is present (or absent), which catches pages that return 200 while showing an error.
- Ping and port: confirm that a host answers ICMP or that a specific TCP port such as a mail or database service accepts connections.
- DNS: resolve a hostname and compare the answer with the records you expect, to catch misconfiguration or hijacking.
- SSL certificate: read the certificate on a hostname and warn before it expires.
- Heartbeat: the reverse of a normal check, where your scheduled job pings the monitor and you are alerted if a ping does not arrive on time.
Interval, timeout and thresholds
Three settings shape almost every uptime monitor. The check interval controls how quickly you learn about an outage; a five-minute interval means a failure may go unnoticed for up to five minutes, while a thirty-second interval catches it far sooner but generates more traffic. The timeout decides how long a request may take before it counts as failed. Ten seconds suits most APIs; slow legacy pages may need longer.
The fail threshold is the number of consecutive failures before a location is considered down. A threshold of two or three removes most noise from transient network errors at the cost of a slightly later alert. Multi-region confirmation adds a second filter on top: several locations must agree before anyone is paged.
Why check from outside your own network?
Internal health checks are valuable, but they share fate with the thing they watch. If a data centre loses its network, the server that would have reported the problem is cut off too. A DNS mistake, an expired certificate, a misconfigured load balancer or a firewall rule can all make a service unreachable to customers while every internal dashboard stays green.
External monitoring from several regions sees the service the way users see it, including DNS resolution, TLS handshakes and the full path across the public internet. It also gives you an independent record of availability that does not depend on the systems being measured.
How MoniterMySite handles this
MoniterMySite offers seven monitor types: HTTP(S), keyword, ping, port, DNS, SSL certificate and heartbeat. Checks run from five regions on four continents (New York, San Francisco, Frankfurt, Singapore and Sydney) and rotate between the regions you select. The fastest interval depends on the plan, from every five minutes on the free Starter plan to every ten seconds on Summit. Once a monitor is down it is re-checked every minute so recovery is noticed quickly. Alerts can go to email, webhooks, Slack, Discord, Microsoft Teams, Google Chat, Telegram and PagerDuty, and every plan includes unlimited team members.
Frequently asked questions
How often should a website be checked?
Match the interval to the cost of not knowing. A personal site or internal tool is fine at five minutes. A customer-facing product is usually checked every thirty to sixty seconds, and payment or API platforms often use ten-second intervals so an outage is confirmed within a minute.
Does uptime monitoring affect my analytics or server load?
The load is tiny: one small request per interval per region. Monitoring services identify themselves with a distinctive user agent so you can exclude the requests from analytics and allowlist them in firewalls.
What is the difference between uptime monitoring and application performance monitoring?
Uptime monitoring observes a service from outside and answers whether it is reachable and responding in time. Application performance monitoring instruments the code itself to explain why it is slow or failing. Most teams use both: the first tells you something is wrong, the second helps you find the cause.
Keep reading
See it in practice.
Add your first monitor on the free plan in under a minute. Multi-region confirmation is included from the Launch plan.