Production Readiness Checklist: CDN and Web Infrastructure Verification

Launching web infrastructure into production without systematic verification is the leading cause of preventable outages. A CDN misconfiguration that caches authenticated responses, a missing security header that enables clickjacking, or an untested failover path that silently drops traffic — each of these has caused real incidents at organizations that skipped pre-launch verification. This checklist distills the critical verification steps that infrastructure teams should complete before any production CDN deployment, covering DNS, SSL/TLS, caching, security, performance, monitoring, and operational readiness. Treat it as a mandatory gate, not optional guidance.

What DNS and Domain Verification Steps Are Required Before Launch?

DNS misconfiguration is the most common source of production launch failures because DNS errors are silent — they do not generate application errors, only unreachable endpoints. The DNS resolution chain must be verified end-to-end before any traffic migration.

CNAME or A/AAAA record validation: Verify that the production domain resolves to the CDN provider's endpoint. For CNAME configurations, confirm the CNAME target matches the CDN distribution exactly (including any trailing dots in the zone file). For direct A/AAAA records with anycast addressing, verify records point to the CDN's announced IP ranges, not the origin server's IP. Test from multiple DNS resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, and your ISP's resolver) to catch propagation issues.

TTL verification: Before switching DNS to the CDN, lower the TTL on existing records to 300 seconds (5 minutes), wait for the old TTL to expire, then make the switch. This ensures rapid rollback if issues are discovered. After the launch stabilizes (typically 48-72 hours), increase TTLs to production values — 3600 seconds for CDN CNAMEs, 300-600 seconds for failover-capable configurations. Review DNS propagation and TTL mechanics if this is unfamiliar territory.

DNSSEC validation: If the domain uses DNSSEC, verify that the chain of trust remains intact after adding CDN records. DNSSEC validation failures cause hard DNS resolution failures with no fallback — the domain simply stops resolving for DNSSEC-validating resolvers. Test with dig +dnssec and online DNSSEC analyzers after any DNS change.

Apex domain handling: Verify that the naked domain (example.com without www) works correctly. Many CDN providers require ALIAS/ANAME records or their own DNS hosting for apex domains because CNAME records at the zone apex violate RFC standards. If using a redirect from apex to www (or vice versa), verify the redirect chain includes HTTPS and preserves the full URL path.

How Should SSL/TLS Configuration Be Validated?

Certificate issues are the second most common launch-day failure. A misconfigured SSL/TLS setup can result in browser security warnings that immediately destroy user trust, or worse, silently serve unencrypted content.

Certificate chain completeness: Verify the complete certificate chain is served — leaf certificate, intermediate certificates, and root CA. Missing intermediates cause failures in Android browsers and older systems that don't have the intermediate cached. Test with openssl s_client -showcerts -connect domain:443 and verify the chain builds correctly. CDN providers typically manage this automatically, but custom certificate uploads frequently have chain issues.

Certificate coverage: Confirm the certificate covers all required hostnames: the apex domain, www subdomain, and any additional subdomains (api, assets, static). A certificate for example.com does not cover www.example.com unless explicitly included as a Subject Alternative Name (SAN). Wildcard certificates (*.example.com) cover single-level subdomains but not the apex or multi-level subdomains like api.v2.example.com.

Protocol and cipher configuration: Verify TLS 1.2 and TLS 1.3 are enabled, and TLS 1.0/1.1 are disabled. Test cipher suite ordering to ensure strong ciphers (ECDHE with AES-256-GCM) are preferred. Modern CDN providers handle cipher configuration automatically, but verify the CDN's settings match your security requirements, particularly for compliance scenarios requiring specific cipher suites.

HSTS configuration: Deploy HTTP Strict Transport Security headers with appropriate max-age. Start with a short max-age (300 seconds) during launch, then increase to production values (31536000 seconds / 1 year) after confirming everything works. Include the includeSubDomains directive only if all subdomains support HTTPS. The preload directive should only be added after thorough testing because removal from browser preload lists takes months.

What CDN Cache Configuration Must Be Verified?

Cache misconfiguration creates two failure modes: under-caching causes origin overload during traffic spikes, and over-caching serves stale or incorrect content to users. Both require careful pre-launch verification.

Cache-Control header audit: Review Cache-Control headers for every content type. Static assets (CSS, JS, images, fonts) should have max-age=31536000 (1 year) with content-based filenames for cache busting. HTML pages should use max-age=0, must-revalidate or short TTLs (300-600 seconds) with stale-while-revalidate for availability. API responses require careful per-endpoint analysis — public endpoints may be cacheable while authenticated endpoints must include Cache-Control: private, no-store.

Cache key validation: Verify the cache key design excludes parameters that should not differentiate cached responses. Marketing UTM parameters (utm_source, utm_medium, etc.), session identifiers in query strings, and sort/filter parameters on paginated APIs should typically be excluded from cache keys. Conversely, ensure parameters that genuinely differentiate content (locale, page number, API version) are included. Incorrect cache key configuration is the most common cause of cache poisoning incidents.

Cache behavior testing: Send identical requests through the CDN and verify response headers. Confirm X-Cache: HIT (or the CDN's equivalent header) on the second request. Test with different Accept-Encoding values to verify compression variants are cached correctly. Verify that Vary headers are minimal and correct — an overly broad Vary header destroys cache efficiency, while a missing Vary header for content negotiation serves wrong content types.

Cache invalidation testing: Before launch, verify the cache invalidation mechanism works. Publish a test page, cache it, then purge and confirm the updated version serves. Measure purge propagation time across all edge locations — if global purge takes 30 seconds, your incident response plan must account for that delay.

What Security Hardening Must Be Complete Before Launch?

Security configuration gaps discovered after launch often cannot be remediated without service disruption. Complete these checks before any production traffic flows through the CDN.

WAF rule validation: The web application firewall must be in blocking mode (not just detection/logging mode) for production. Validate that WAF rules correctly block common attack patterns (SQL injection, XSS, path traversal) without blocking legitimate requests. Test with a suite of known-safe attack patterns and verify blocks, then test with legitimate edge-case requests (URLs containing encoded characters, large POST bodies, non-standard Content-Types) and verify they pass.

DDoS protection verification: Confirm DDoS protection is enabled and configured with appropriate thresholds. Layer 3/4 protection should be automatic. Layer 7 protection requires tuning — rate limits must be high enough to accommodate legitimate traffic bursts (product launches, email campaigns) while low enough to mitigate application-layer attacks. Set rate limits at 3-5x expected peak legitimate traffic as a starting point.

Security header audit: Verify all security headers are present in responses: Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options, Referrer-Policy, and Permissions-Policy. Test CSP in report-only mode first (Content-Security-Policy-Report-Only) to identify legitimate resources that would be blocked, then switch to enforcing mode before launch.

Origin protection: Verify that the origin server only accepts traffic from the CDN's IP ranges. Configure origin firewall rules to deny all traffic except from the CDN provider's published IP ranges. Test by attempting to access the origin directly — the connection should be refused. Without origin protection, attackers can bypass all CDN-layer security by connecting directly to the origin IP.

How Should Performance Baselines Be Established?

Without pre-launch performance baselines, you cannot distinguish degradation from normal behavior after launch. Baselines provide the reference points that make performance metrics actionable.

Synthetic monitoring baseline: Run synthetic tests from at least 5 geographic regions representing your primary user base for a minimum of 48 hours before launch. Measure Core Web Vitals (LCP, FID/INP, CLS), TTFB, and full page load time on both desktop and mobile profiles. Establish p50, p95, and p99 targets for each metric. These baselines become the threshold values for post-launch alerting.

Load testing: Conduct load tests at 2x and 5x expected peak traffic through the CDN (not directly against the origin). Load tests should run for a minimum of 30 minutes at sustained load to surface resource exhaustion issues that short burst tests miss — connection pool depletion, memory leaks, and file descriptor limits typically manifest after 10-15 minutes of sustained load. Document the breaking point where error rates exceed 1% or response times exceed SLA thresholds.

Cache warming: Before directing production traffic, warm CDN caches using cache warming scripts that request the most popular pages and assets. Cold cache performance during the first minutes after launch can be dramatically worse than warm cache performance — TTFB increases from 50ms to 800ms+ when requests hit origin instead of cache. For multi-PoP CDNs, warm at least the PoPs serving your highest-traffic regions. Monitor cache hit ratios during warming to confirm caching behavior before production traffic arrives.

What Monitoring and Alerting Infrastructure Must Be Ready?

Monitoring infrastructure must be fully operational before launch — discovering a monitoring gap during an incident is the worst possible time. The monitoring and observability stack should cover four dimensions.

Availability monitoring: Deploy uptime checks from at least 3 geographic regions at 1-minute intervals. Checks should verify full page response (not just TCP connectivity) by validating HTTP status code, response body content, and response time. Configure alerts to page the on-call engineer after 2 consecutive failures from the same region, or 1 failure from 2+ regions simultaneously. The health check and failover system should automatically redirect traffic away from unhealthy origins.

Performance monitoring: Real user monitoring (RUM) captures actual user experience across devices, browsers, and network conditions. Synthetic monitoring provides consistent baselines from controlled environments. Both are necessary — RUM shows real-world problems, synthetics provide early warning of infrastructure issues before users notice. Set alert thresholds at p95 latency exceeding baseline by 50% and p99 exceeding baseline by 100%.

Error monitoring: Track 4xx and 5xx error rates separately. A 4xx spike usually indicates routing or configuration issues (broken redirects, missing assets after deployment). A 5xx spike indicates origin health problems. Alert when error rates exceed the baseline plus 2 standard deviations sustained for 5 minutes. For API endpoints, also monitor business-logic errors (validation failures, authorization denials) as leading indicators of attacks or configuration issues.

Operational readiness: Document incident response procedures including: on-call rotation with at least 2 engineers per shift, escalation paths with contact information for CDN provider support, rollback procedures with estimated time to execute, and communication templates for status page updates. Conduct a tabletop exercise walking through the top 5 failure scenarios (origin outage, CDN cache poisoning, SSL certificate expiration, DDoS attack, DNS propagation failure) to verify the team can execute response procedures under pressure.

Completing this checklist does not guarantee a flawless launch — unexpected issues arise in every production deployment. What it guarantees is that the known failure modes have been addressed, monitoring will detect problems within minutes, and the team has practiced response procedures. The difference between a minor launch hiccup and a major incident usually comes down to preparation, not luck. Use this as a starting template, then customize it with lessons learned from each deployment to build institutional knowledge that makes every subsequent launch smoother. Integrate it with your infrastructure automation to enforce checks programmatically rather than relying on manual verification, and review it quarterly against the troubleshooting patterns your team encounters most frequently.