When a business website becomes slow, unreliable, or unreachable, a calm response depends on preparation. This runbook gives small teams a practical system for website uptime monitoring, alert review, outage triage, customer communication, and post-incident improvement.
Overview
Website uptime monitoring is more than checking whether a homepage loads. A useful monitoring setup tests the parts that affect customers and business operations: DNS resolution, TLS certificates, HTTP responses, key pages, application functions, databases, hosting resources, and important third-party services.
The goal is not to eliminate every interruption. The goal is to detect meaningful problems quickly, identify the likely failure area, communicate clearly, and restore normal service without making the incident worse. For a small business, this reduces guesswork and helps protect leads, orders, bookings, account access, and customer trust.
Start with a simple inventory of your production website. Record the primary domain, hosting account, DNS provider, certificate manager, content management system, database, payment or form provider, analytics tools, and the people who can access each system. Keep this information in a shared location that remains available when the website itself is down.
Pair monitoring with a tested recovery plan. The website backup and disaster recovery restore-test checklist can help you verify that backups are usable rather than merely present.
What to track
Build a monitoring baseline
Use several check types instead of relying on one homepage request. A practical baseline includes:
- Availability: Check the homepage and one or two important URLs from outside your hosting environment.
- HTTP behavior: Record response status, redirect behavior, response time, and whether the expected page content appears.
- DNS: Confirm that the domain resolves correctly and that important records have not changed unexpectedly.
- TLS certificates: Monitor certificate validity and renewal status, including the exact hostname customers use.
- Application paths: Test a sign-in page, contact form, checkout flow, booking form, or other revenue-critical action where practical.
- Infrastructure limits: Watch storage, memory, CPU, database connections, bandwidth, and request limits exposed by your hosting platform.
- Dependencies: Track payment processors, email delivery, identity providers, CDN services, APIs, and embedded tools that can affect the user experience.
Define the normal range before setting alerts. A response that is slightly slower during a brief traffic spike may not require the same response as repeated failures on a checkout endpoint. Record normal response times during ordinary traffic and note predictable maintenance or campaign periods.
Alert-threshold reference
| Signal | Suggested first alert | Escalate when | Typical first check |
|---|---|---|---|
| Availability | Two failed checks from more than one location | Failures continue for five minutes or affect a critical path | Hosting dashboard, DNS, recent deployments |
| HTTP errors | Repeated 5xx responses or a sudden increase in 4xx errors | Errors affect key pages, forms, or logged-in users | Application logs and release history |
| Response time | Several readings above the established baseline | Users cannot complete important actions or the trend persists | Hosting resource graphs, database, third-party calls |
| Certificate | Renewal or validity warning | Certificate mismatch, expiration, or browser security warning | Certificate configuration and DNS validation |
| Resources | Usage remains near the plan or server limit | Requests fail, processes are terminated, or capacity is exhausted | Traffic, logs, caching, queries, and hosting limits |
| Business transaction | One failed synthetic test | Two consecutive failures or confirmed customer impact | Form, payment, email, and application logs |
These are starting points, not universal rules. Adjust them to the website’s traffic, revenue impact, operating hours, and recovery capability. Avoid alerting on every minor variation; noisy alerts train people to ignore important ones.
Use a simple incident triage decision tree
- Is the problem confirmed? Test from a second network or monitoring location. If only one person sees it, check local DNS, browser cache, or network conditions.
- Does the domain resolve? If not, inspect DNS records, nameservers, registrar status, and recent changes. Use the DNS records setup guide as a reference.
- Does HTTPS work? If DNS resolves but the browser reports a certificate problem, check certificate coverage, renewal, redirects, and proxy settings. See the SSL and HTTPS checklist.
- Is the server responding? A 5xx response usually points toward the application, runtime, database, or hosting environment. A 4xx response may indicate routing, permissions, authentication, or an incorrect request.
- Did a recent change precede the issue? Review deployments, plugin updates, configuration edits, DNS changes, and infrastructure adjustments. If a safe rollback is available, use the documented procedure.
- Is a dependency failing? Test forms, payments, email, APIs, and identity services individually. A functioning homepage does not prove that the business workflow works.
Cadence and checkpoints
A monitoring system needs regular review so it remains useful after the website changes. Assign an owner and use a recurring schedule.
Daily or on each workday
- Review unresolved alerts and confirm that critical checks are reporting normally.
- Look for repeated failures, not just isolated events.
- Check the status of active incidents and record who is responsible for the next action.
Monthly
- Run the most important customer journey manually: for example, submit a form, complete a test booking, or verify account access.
- Test alert delivery to the primary and backup contacts.
- Review uptime, response-time trends, HTTP error counts, and hosting resource usage.
- Confirm that the monitoring list still includes every production domain and critical endpoint.
- Check that backups exist and that a recent restore test is documented.
Quarterly
- Run a short outage drill using a hypothetical DNS, certificate, application, database, or third-party failure.
- Verify escalation contacts, access permissions, recovery targets, and the location of credentials or emergency instructions.
- Review whether hosting capacity matches traffic and application demand. A cloud hosting cost review can help connect reliability decisions with resource usage.
- Review staging and production separation before major releases. The production versus staging workflow provides a practical reference.
After a launch or infrastructure change, run additional checks rather than waiting for the normal calendar. One-click deployment is convenient, but every release should still have a clear rollback path and a post-release verification step.
How to interpret changes
Interpret monitoring data as a pattern, not a single number. A brief failed check may be a monitoring-path issue. Repeated failures from multiple locations are stronger evidence of customer impact. Compare the timing of alerts with deployments, traffic changes, DNS edits, certificate events, scheduled jobs, and provider notices.
HTTP status codes provide useful direction:
- 2xx: The request was generally successful, but verify that the expected content or workflow completed.
- 3xx: Redirects may be intentional, but loops, unexpected destinations, or long redirect chains can break access and slow pages.
- 4xx: Investigate routing, permissions, authentication, missing pages, invalid requests, or security controls.
- 5xx: Check application logs, runtime health, database connectivity, deployment changes, and hosting capacity.
When the site is reachable but unreliable, separate availability from usability. A homepage may return successfully while a form fails because of a script, API, database, or email dependency. Capture the exact URL, time, status code, response duration, user action, and error message before changing anything. This evidence shortens diagnosis and supports a useful post-incident review.
Status-page communication template
Use plain language and publish only confirmed information:
Investigating: We are investigating an issue affecting [website or feature]. Some visitors may experience [specific symptom]. The next update will be provided by [time or condition].
Identified: We have identified a problem involving [affected component]. The team is applying a fix and monitoring results.
Monitoring: Service has been restored, and we are monitoring the website for continued stability. If you still experience a problem, please [contact method].
Resolved: The incident was resolved at [time]. We will review the cause and follow-up actions.
Do not promise a recovery time unless the team can support it. Link customers to an independent status page or communication channel when the primary website is unavailable.
When to revisit
Review this runbook monthly for alert and contact checks, and perform a deeper update at least quarterly. Revisit it immediately after an outage, hosting migration, domain or DNS change, certificate change, major browser or platform change, new payment or email integration, or significant website release.
Post-incident review checklist
- What time did the issue begin, and when was it detected?
- What customer journeys, locations, devices, or services were affected?
- Which signal confirmed the incident?
- Was the root cause DNS, a certificate, an application error, database failure, hosting capacity, a deployment, or a third-party service?
- Which actions restored service, and which actions added delay or risk?
- Was communication timely, accurate, and accessible?
- Did monitoring detect the issue early enough?
- What permanent action will prevent recurrence or reduce recovery time?
- Who owns each action, and when will it be verified?
Keep the review blameless and specific. The outcome should be an improved check, clearer documentation, safer deployment, capacity adjustment, backup test, or escalation path—not just a description of what went wrong. For launch and deployment controls, consult the one-click website deployment guide and the small business site operations playbook.
To put this into practice today, choose three checks: homepage availability, one revenue-critical workflow, and certificate or DNS health. Assign an alert owner, test the notification, record the baseline, and schedule the next monthly review. A small, maintained system is more valuable than a complex monitoring setup nobody checks.
