Uptime Monitoring Checklist: What to Check, When to Check It, and What to Do

A basic uptime check asks whether a URL returns a successful response. But a useful uptime check covers more: the specific URL being checked (not just the homepage), the HTTP status code returned, any redirect chain behavior, and the response time alongside the availability status.

For most business websites, the pages that matter most are not always the homepage. A booking form that fails, a checkout page that times out, or a login portal that returns an error can each represent complete unavailability for the visitor trying to complete that action — even if the homepage loads perfectly.

For agencies, this means uptime checks should cover the pages that matter most to the client's business: the contact or booking page, the checkout flow, the client portal, and any campaign landing pages that are actively driving traffic.

• Homepage URL included in every check
• Booking, checkout, or contact page included for sites where these are business-critical
• Any client portal or login page checked separately
• Active campaign landing pages included during campaign periods
• Subdomain availability checked separately if critical business functions run on subdomains

Understanding what status codes mean is necessary for interpreting uptime check results. A 200 OK means the server responded successfully. A 301 or 302 means a redirect is in place. A 404 means the page was not found — a common result when a URL changes. A 500 means the server encountered an error processing the request.

Redirect responses (301, 302) are not failures — they indicate the server is working and directing traffic to the correct URL. But an unexpected redirect chain — a URL that redirects three times before reaching the final destination — may indicate a configuration issue worth reviewing.

Error responses (4xx, 5xx) indicate problems that warrant investigation. A 404 on a URL that was previously returning 200 means the page content has been removed or the URL structure has changed. A 500 means a server-side error that requires investigation of server logs or application configuration.

• 200 OK: site is responding normally
• 301/302 Redirect: responding, but redirecting to another URL — verify the final destination
• 403 Forbidden: server responding but blocking access — check authentication or IP restriction configuration
• 404 Not Found: page does not exist at this URL — verify the URL is correct
• 500 Server Error: server-side problem requiring investigation
• No response / timeout: connectivity or DNS issue requiring urgent investigation

Uptime checks should include response time alongside availability status. A site that is technically 'up' but responding in five seconds is functionally unavailable for most mobile visitors. Response time gives you the quality dimension of availability, not just the binary up-or-down.

General response time benchmarks: under 200ms is fast, 200ms to 500ms is good, 500ms to 1 second is acceptable but worth monitoring, over 1 second warrants investigation, over 2 seconds is affecting visitor experience and likely conversions.

Track response time over time rather than just at a single point. A site that was running at 300ms last month and is now running at 1.2 seconds has a problem worth investigating — even if the current response time is still technically within acceptable limits.

• Is current response time within expected range for this site?
• Has response time changed significantly from the previous check?
• For ecommerce: is checkout response time under 1 second?
• For high-traffic pages: is response time acceptable under typical load?
• For mobile audiences: is response time fast enough for slower mobile connections?

When an uptime check reveals that a site is unavailable, the response process matters as much as the detection. A structured response process reduces the time from detection to resolution and creates documentation of what happened.

First, verify the finding: run the check again from the same tool and also try loading the URL in an incognito browser window on a different network. One failed check may be a transient network issue. Two failed checks from different sources indicate a real problem.

Then identify the likely cause: check the hosting provider status page, verify DNS is resolving correctly, check for any recent site changes that might have caused the issue, and check whether the SSL certificate is expired or the domain has lapsed. The health check result will indicate which signal failed and give you a starting point for the investigation.

• Verify the outage with a second check from a different source
• Check the hosting provider's status page for any active incidents
• Verify DNS is resolving to the correct IP address
• Check for any recent deployments, updates, or configuration changes
• Check whether SSL certificate has expired
• Check whether domain registration is current
• Contact hosting provider support if the cause is not immediately apparent
• Notify the client if the outage is significant and resolution will take time
• Document the timeline: when the issue was detected, what was investigated, and when it was resolved