How uptime monitoring works
A monitoring service requests a URL on your site at a fixed interval, typically every 1 to 60 minutes, and records whether it answered, the HTTP status code and how long it took. When checks fail, it opens an incident and alerts you; when they succeed again, it sends a recovery notice.
What counts as "down"
- No answer: a timeout, DNS failure, refused connection or TLS error.
- Server errors: HTTP 5xx responses such as 500, 502 and 503.
- Wrong content: the server answers 200, but with an error page, a blank page or a defaced site. Only a keyword check catches this.
- Too slow: many services treat responses above a threshold as "degraded" rather than down.
Avoiding false alarms
Single failed checks happen: a brief network blip between the monitor and your server, a slow database query. Good monitoring confirms before alerting, by requiring several consecutive failures or by re-checking from another location. Fewer false alarms means people keep paying attention to real ones.
What uptime percentages really mean
| Uptime | Downtime per month | Downtime per year |
|---|---|---|
| 99% | About 7.3 hours | About 3.65 days |
| 99.5% | About 3.65 hours | About 1.83 days |
| 99.9% | About 43.8 minutes | About 8.77 hours |
| 99.99% | About 4.4 minutes | About 52.6 minutes |
Your measured uptime depends on how often you check. With checks every 30 minutes, a 10-minute outage might be missed entirely, or counted as 30 minutes. Shorter intervals give more accurate numbers and faster alerts.
Response time
Response time is how long the server takes to answer. Averages hide problems, so look at the 95th percentile too: the time that 95% of checks beat. A rising trend often warns of a full disk, a growing database or a plugin problem before the site actually goes down.
Beyond up or down
Several failures look like outages to visitors but are not caught by a basic check:
- Certificate expiry: an expired certificate shows a full-page browser warning. Monitor expiry dates and get warned weeks ahead. See how to fix SSL errors.
- Domain expiry: a lapsed domain takes the website and email down together.
- DNS changes: an unexpected change to nameservers or records can mean a hijacked registrar account.
- Content changes: a new external script on your homepage can be a card skimmer.
- Security header changes: a deployment that drops HSTS or CSP weakens the site silently.
Choosing a monitoring service
- Interval: how often it checks on the plan you can afford.
- Confirmation: does it re-check before alerting, and from where?
- Alert channels: email, chat (Slack, Teams, Discord), webhooks, SMS.
- Keyword checks and response-time thresholds.
- Status pages to share with customers.
- Honest reporting: uptime figures computed only from checks that actually ran.
How Webforta Monitor works
Webforta Monitor checks your homepage over HTTPS at your chosen interval. Minimum intervals depend on the plan: Free 60 minutes, Starter 30 minutes, Pro 10 minutes, Business 5 minutes. A scheduler dispatches checks every 5 minutes, so spacing can vary by a few minutes.
A site is declared down only after the configured number of consecutive failures (default 2), and the check is repeated from a second region before an incident opens. Regular checks run from one location on Cloudflare's network; Webforta is not a network of probes in many countries and does not send SMS. Alerts go to email, Slack, Discord, Microsoft Teams and signed webhooks on paid plans and during the trial; the Free plan shows results in your account only.
On top of availability, Webforta Monitor runs optional keyword checks, warns about certificate expiry (from Certificate Transparency logs, daily) and domain expiry (via RDAP), snapshots DNS records hourly, tracks new external scripts and iframes on the homepage, and alerts when security headers change. Public status pages and reports use only recorded checks.