Website Monitoring Checklist: The Complete Setup Guide for Uptime, SSL, DNS, and More

Add your main website URL (e.g., https://www.example.com) as a monitored target. Use HTTPS, not HTTP, so the check also verifies SSL connectivity. Set the check interval to 30-60 seconds for production sites.

Add your login page, dashboard, or primary application URL. The homepage is often served from cache and stays up while the application server is down. Monitoring an authenticated endpoint catches application-level failures that homepage monitoring misses.

If you have a public or internal API, monitor its health endpoint (e.g., /api/health or /api/v1/status). Configure the check to validate the response body, not just the status code. A 200 response with an error message is still a failure.

Identify the pages that generate revenue or are essential to your product: checkout pages, signup forms, payment confirmation pages. Add each as a separate monitored target with keyword validation to ensure the page content is correct.

Add monitoring for every active subdomain: blog.example.com, docs.example.com, app.example.com, api.example.com, staging.example.com. Each runs on different infrastructure and can fail independently.

Configure uptime checks from at least three geographic locations. This distinguishes between global outages and regional network issues, and prevents false positives from transient routing problems at a single monitoring location.

Define acceptable response times for each target. Web pages should respond within 2-5 seconds. API endpoints should respond within 500ms-2 seconds. Alert when response times consistently exceed these thresholds, even if the site is technically up.

Require at least two consecutive failures from multiple locations before triggering an alert. This eliminates false positives from momentary network blips without significantly delaying real outage detection.

Add every domain and subdomain to SSL monitoring. Each may have a different certificate with a different expiration date. Wildcard certificates cover subdomains but not the apex domain, so monitor both.

Configure alerts at 30 days, 14 days, and 7 days before certificate expiration. The 30-day alert gives you time to investigate calmly. The 7-day alert is your emergency backstop.

Ensure your monitoring tool checks the full certificate chain, not just the leaf certificate. Missing intermediate certificates cause failures on mobile browsers and API clients while appearing fine in desktop browsers.

For each certificate, record how it is provisioned and renewed: Let's Encrypt via Certbot, paid certificate via registrar, CDN-managed certificate, or cloud provider auto-provisioned. When an alert fires, the responder needs to know where to look.

After any server migration, web server configuration change, or certificate renewal, verify that the correct certificate is being served with a complete chain. Add this to your deployment checklist.

Audit every domain your organization owns. Include primary domains, regional variants (.co.uk, .de), defensive registrations (common misspellings), legacy domains, and domains used for internal services or email.

Add every domain to expiry monitoring. Configure alerts at 90, 60, 30, 14, and 7 days before expiration. The 90-day alert covers you even if a domain has a short registration period remaining.

For each domain, log into the registrar and confirm auto-renewal is enabled, the payment method is current, and the contact email is monitored by an active team member. Document this verification.

Ensure at least two team members have access to every registrar account. Document account credentials in your team's password manager. A domain managed by a single person's personal account is a ticking time bomb.

For every domain, enable the registrar lock (clientTransferProhibited). This prevents unauthorized domain transfers. Verify the lock status is part of your domain monitoring.

Export a complete snapshot of your DNS zone for each domain. Review every record to confirm it is correct and intentional. This snapshot becomes the reference point that monitoring compares against.

Track the IP addresses your domains resolve to. Any change means your traffic is going to a different server. This is the most direct indicator of DNS hijacking.

Track all CNAME aliases, especially for subdomains pointing to third-party services (CDNs, hosting platforms, SaaS tools). Watch for dangling CNAMEs that could enable subdomain takeover attacks.

Track your email routing records. Unauthorized MX changes redirect your email to an attacker's server. This is one of the highest-impact DNS attacks because it is silent and provides access to sensitive communications.

Track SPF, DKIM, and DMARC records. These control email authentication and domain verification. A weakened DMARC policy or altered SPF record enables phishing attacks using your domain.

Track your nameserver delegation. An NS record change hands control of your entire DNS to different nameservers. This should be exceedingly rare. Any unexpected NS change is a critical security event.

Identify and remove DNS records that point to decommissioned services, old IP addresses, or unused subdomains. Stale records are attack vectors. If a CNAME points to a service you no longer use, remove it.

List every external service your site depends on: CDN (Cloudflare, Fastly, AWS CloudFront), payment processor (Stripe, PayPal), email service (SendGrid, Mailgun, Postmark), analytics (Google Analytics, Mixpanel), authentication (Auth0, Okta), database (PlanetScale, Supabase, MongoDB Atlas), and hosting (Vercel, Netlify, AWS, GCP).

Add each vendor's status page to your monitoring. Most major services publish status at status.vendor.com. When they report an incident, you need to know immediately to assess impact on your users.

For critical integrations, monitor the vendor's API health endpoint directly. Status pages are sometimes updated slowly. A direct health check detects issues faster than waiting for the vendor to acknowledge them.

For each vendor, document what user-facing functionality breaks when they go down. Stripe outage = checkout broken. SendGrid outage = transactional emails delayed. Cloudflare outage = entire site unreachable. This mapping speeds up incident response.

For the most critical dependencies, document fallback procedures. Can you bypass the CDN and serve directly? Can you switch to a backup payment processor? Can you queue emails for retry? Having a plan before a vendor outage saves critical minutes during an incident.

Confirm that http://yourdomain.com redirects to https://yourdomain.com with a 301 (permanent) redirect. Test both the apex domain and www subdomain. A missing redirect means some users access your site without encryption.

Confirm that your chosen canonical URL (www or non-www) is enforced via 301 redirect. Both versions should work, with one redirecting to the other. Inconsistent behavior splits your SEO equity.

Identify URLs that redirect through multiple hops before reaching the final destination. Each hop adds latency and increases the chance of a broken link. Chains of three or more redirects should be consolidated to a single redirect.

If you have redirects from old URLs to new ones (after a site restructure or rebrand), monitor that these redirects continue to work. A deployment that accidentally removes redirect rules can break hundreds of inbound links overnight.

Check that your CSP header is present and correctly configured. A missing or overly permissive CSP leaves your users vulnerable to XSS attacks. A CSP that is too restrictive breaks your own site's functionality.

Check that your HSTS header is present with an appropriate max-age (at least 31536000 seconds / one year). Include the includeSubDomains directive if all subdomains use HTTPS. This prevents SSL stripping attacks.

Ensure your site cannot be embedded in iframes on other domains unless intentionally allowed. This prevents clickjacking attacks where an attacker overlays your site with invisible elements.

Check that this header is set to "nosniff" to prevent browsers from MIME-type sniffing responses, which can be exploited to execute malicious content.

After deployments, verify that security headers have not been accidentally removed or weakened. A common pattern is a new web server configuration or CDN rule that strips custom headers without the team noticing.

Document the typical response time for your key pages under normal load. When monitoring detects a sustained increase above this baseline, investigate before it becomes a user-facing issue.

TTFB measures server processing time, independent of page size or client-side rendering. A TTFB increase indicates server-side performance degradation: database slowdowns, inefficient queries, or resource contention.

Configure alerts when response times exceed 2x your baseline for more than 5 consecutive checks. This catches performance degradation that has not yet caused a full outage but is affecting user experience.

Set up at least two channels: email plus a real-time channel (Slack, Microsoft Teams, or SMS). Email alone is not fast enough for production outages. Real-time channels alone risk being missed if the person is away from their desk.

Route alerts to the people who can act on them. Uptime alerts go to the on-call engineer. SSL alerts go to the infrastructure team. Domain alerts go to the team that manages registrar accounts. Sending all alerts to everyone creates noise.

If the primary responder does not acknowledge an alert within 15 minutes, escalate to a secondary contact. If no one responds within 30 minutes, escalate to management. Alerts that go unacknowledged are alerts that do not exist.

After your first week of monitoring, review all alerts. Eliminate false positives by adjusting thresholds and confirmation requirements. Every alert should require action. If you are dismissing alerts habitually, your thresholds are wrong.

Deliberately trigger a test alert through each channel to verify it reaches the right people. An alert pipeline you have never tested is an alert pipeline you cannot trust during a real incident.

Document the step-by-step process for responding to each alert type: who to contact, where to look, what to check first, and how to escalate. A 3 AM outage is not the time to figure out who has server access.

Maintain a list of everything you monitor, why it is monitored, and what team owns it. When a new team member joins, they should be able to understand your monitoring setup in 15 minutes.

Set a recurring calendar event to review your monitoring setup every quarter. Add new targets for new services. Remove monitoring for decommissioned services. Update alert routing for team changes. Monitoring that does not evolve with your infrastructure becomes stale.