The worst way to learn your website is down is from a customer, a sales manager or a social media post. Yet that is how many businesses still find out. Good website uptime monitoring detects problems within minutes, tells the right person, and connects to a response plan that people have actually practised. This guide covers what to monitor, how to handle alerts without drowning in noise, and how to run incidents calmly from first alert to final review.
What "up" really means
A basic monitor checks whether the home page returns a successful response. That is a useful start but misses many real failures:
- The home page loads, but the checkout throws an error.
- The site responds, but takes far too long to be usable.
- The page loads, but shows a database error message with a normal status code.
- The site works, but the SSL certificate expires tomorrow.
- Everything looks fine, but contact form emails stopped sending last week.
Monitoring should reflect what your business actually depends on, not just whether a server answers.
What to monitor
| Check | What it detects | Suggested frequency |
|---|---|---|
| HTTP status from multiple locations | Site down, DNS or network failures | Every 1–5 minutes |
| Keyword or content check | Error pages returned with a normal status | Every 1–5 minutes |
| Response time thresholds | Slowdowns before full outages | Every 1–5 minutes |
| Critical user journeys (synthetic) | Broken login, search, cart or forms | Every 15–60 minutes |
| SSL certificate expiry | Upcoming expiry or misconfiguration | Daily |
| Domain expiry | Domain registration lapsing | Daily or weekly |
| Server resources | Disk, memory, CPU, database connections | Every minute |
| Scheduled jobs and queues | Failed cron jobs, stuck queues | After each run |
| Application errors | Spikes in exceptions or failed requests | Continuous |
| Backups | Failed or missing backup jobs | After each run |
Two of these deserve special mention. Domain expiry sounds trivial, but a lapsed domain takes down the website and email together. SSL expiry remains a common cause of avoidable outages; our SSL certificate guide explains how to automate renewals.
Designing alerts people trust
Monitoring fails when people learn to ignore it. The goal is that every alert is real and actionable.
Reduce false alarms
- Require failures from more than one location before alerting.
- Require two or three consecutive failures for non-critical checks.
- Exclude scheduled maintenance windows.
Route by severity
- Critical — site down, checkout broken, data at risk: immediate phone call or push notification to the on-call engineer.
- Warning — slow response, disk filling, certificate expiring in two weeks: chat or email during business hours.
- Information — successful deploys, weekly reports: dashboards only.
Make alerts useful
Each alert should say what failed, where, since when, and link to the dashboard or runbook. "Server problem" helps nobody at 3 a.m.
Key takeaway: Monitor what your customers and revenue depend on, alert only when a human needs to act, and give that human a clear plan. Monitoring without a response process only tells you faster that things are broken.
Incident response: a practical process
Large organizations have formal incident management frameworks. Smaller businesses need a lighter version that still works under pressure.
- Detect. Monitoring alerts the on-call person, or a report arrives from staff or customers through a known channel.
- Acknowledge. The responder confirms they are on it, so others do not duplicate effort or assume someone else is handling it.
- Assess. How many users are affected? Is data at risk? Is this a security incident? Set the severity.
- Communicate. Tell internal stakeholders early, even if the cause is unknown. For customer-facing platforms, update a status page or send a short notice.
- Mitigate. Restore service first: roll back a deployment, fail over, scale up, block abusive traffic, or restore from backup. Root-cause analysis can wait.
- Resolve and verify. Confirm the fix with monitoring and a manual check of critical journeys.
- Review. For significant incidents, write a short blameless review and track the follow-up actions to completion.
Security incidents are different
If an incident might involve unauthorized access to personal information, the steps change: preserve logs and evidence, limit further access, and involve leadership quickly. In Canada, PIPEDA includes breach reporting and record-keeping obligations where there is a real risk of significant harm, and provincial laws such as BC's PIPA may also apply. Other jurisdictions have their own rules. Get legal advice promptly rather than guessing. Our security and compliance services can help you prepare a plan before you need it.
Writing a runbook
A runbook is a short document for each system that answers the questions people ask during an incident:
- Where is it hosted, and how do we access the servers, CDN, DNS and logs?
- Who are the contacts at the hosting provider, domain registrar and key third parties?
- How do we roll back the latest deployment?
- How do we restore from backup? (See our 3-2-1 backup strategy.)
- What are the known failure modes and their usual fixes?
- Who must be informed, and who can approve emergency changes?
Keep it somewhere reachable even when your own systems are down — not only on the server that might be failing.
Measuring and improving
Over time, a few measures show whether things are improving:
- Availability over each month, measured consistently.
- Time to detect — how long between a problem starting and an alert firing.
- Time to resolve — how long until service is restored.
- Repeat incidents — the same cause appearing more than once signals an unfinished fix.
Review these quarterly. Most improvements come from small changes: a missing check, a clearer runbook, an automated renewal, or removing a fragile dependency.
Choosing a monitoring approach
Options range from hosted monitoring services with checks from many regions, to self-hosted tools, to monitoring included in a managed hosting agreement. Whichever you choose, make sure checks run from outside your own hosting environment — a monitor on the same server that fails cannot tell you it has failed.
Communicating during an incident
Technical recovery is only half of incident response. How you communicate shapes how customers and colleagues remember the event.
- Be early. A brief "we are aware of a problem and investigating" message is far better than silence.
- Be specific about impact, not cause. Customers care whether they can place an order or log in, not which server process failed.
- Give a time for the next update, even if you do not yet have a fix, and keep that promise.
- Use one channel as the source of truth, such as a status page or a pinned internal message, so information is not scattered.
- Close the loop. Confirm when service is restored and, for significant incidents, share a short summary of what will change.
Prepare short message templates in advance for common situations — full outage, degraded performance, planned maintenance — so nobody has to write from scratch under pressure.
Practise before you need it
A short exercise once or twice a year pays for itself. Pick a realistic scenario, such as "the database server is unreachable" or "the SSL certificate expired overnight", and walk through who would be alerted, what they would check, how they would restore service and who they would inform. Gaps in access, documentation or contact details are far cheaper to discover in a meeting room than in a real outage.
Next steps
Start with three checks every business website should have today: an external uptime and content check, SSL expiry monitoring and domain expiry monitoring. Then add the journeys that earn you money. DigiVort includes multi-location monitoring, alert routing and incident response in our managed hosting and maintenance and support plans. Get in touch if you would like help designing monitoring that fits your platform.
