Support
We usually reply within 1–2 business days
Ticket submitted!
Your ticket ID:
A confirmation has been sent to your email address.
DevOps Pre-Cutover Validation — Smoke Test Before DNS Cutover | TestURL.live
For DevOps & SREs

Pre-Cutover Validation — Smoke Test The New Origin Before You Flip DNS

You've green-deployed the new origin: EC2 instance, ECS service, App Runner, Fly Machine, K8s ingress — whatever. It works on its IP. But will it work under the production hostname, with the real Host header, the real cookies, the real TLS handshake? TestURL.live gives you a real, browsable preview URL bound to the new origin so you can validate end-to-end before changing Route 53 / Cloudflare.

Works against any IP/origin No agent, no infra changes Validates Host-header routing

The DNS Cutover Risk Surface

You can prove the new origin is healthy a hundred ways before cutover — curl -k https://NEW_IP/, an ALB health check, a synthetic monitor running against the IP, even a Postman collection. None of them actually exercise the production hostname end-to-end. The minute DNS flips, you discover:

A preview URL that proxies the real domain through the new origin reproduces the production routing path without touching production DNS.

Pre-Cutover Validation Playbook

  1. Deploy the new origin (or warm pool / blue stack) and confirm it responds to its own hostname or IP.
  2. Generate a preview URL on TestURL.live: enter the production domain and the new origin's IP. We bind a unique subdomain that proxies through the new IP with Host: yourdomain.com.
  3. Smoke test interactively: open the preview, walk the critical paths (homepage, login, checkout, API endpoint). JavaScript runs, third-party scripts load, cookies set normally.
  4. Run the automated battery: Lighthouse, visual diff against current prod, SEO snapshot, security headers, console-error scan, redirect chain.
  5. Validate auxiliary tooling separately with our standalone SSL Checker, Redirect Chain Checker, and Security Headers Checker.
  6. Cutover when every check is green. Run DNS Propagation Checker against 12 resolvers to confirm the change has landed.
  7. Schedule a 24h re-check — TestURL.live can automatically re-run the suite a day later and email a delta report.

What The Preview Validates

Real Host-Header Routing

The new origin sees Host: yourdomain.com — so vhost selection, cert SNI, and middleware that branches on hostname all behave as in prod.

Console & Network Errors

Headless Chrome captures every browser console error and failed network request — surfaces CSP regressions, broken APIs, missing scripts.

Lighthouse Delta

Performance, accessibility, best practices, and SEO scores for old vs new — catches the regression where the new EC2 type is undersized.

Shareable With Stakeholders

Send the preview URL to QA, the product owner, the CEO. Anyone with the link sees the new origin under the real domain.

Zero-Impact

No DNS change, no production traffic shift, no agent install, no firewall rule. Just an HTTPS preview that you can throw away.

Scheduled Re-Validation

24h / 48h auto re-runs after cutover, with delta PDF emailed automatically — proof for the post-mortem doc.

Use Cases

Blue/Green deployments

Validate the green stack under the production hostname before shifting weighted DNS or the Route 53 alias. Catch config drift between blue and green before users do.

EC2 / cloud VM migrations

Moving from a hand-built EC2 to a new AMI, Auto Scaling Group, or instance family. The preview URL hits the new ASG via its IP — proving the cloud-init bootstrap and userdata produced a working host.

Kubernetes ingress changes

New ingress controller, switched from NGINX to Traefik, added Istio sidecar. Preview the cluster under the prod hostname before updating the external DNS controller.

CDN origin swap

Pointing Cloudflare/CloudFront at a new origin? Validate that origin directly with the prod Host header before the CDN cache fills with errors.

Datacenter / region failover dry-run

Practise DR cutover. Spin up the DR origin and validate it under the production hostname without flipping anything.

Pre-Cutover Validation FAQ

What is pre-cutover validation?

The phase of a migration where you smoke-test the new origin (server, load balancer, CDN, K8s ingress) against the production hostname — before flipping DNS. It catches misrouted vhosts, wrong TLS chains, header-stripping middleware, and stale config that only manifest under the real Host header.

Why use a proxy instead of curl --resolve or /etc/hosts?

curl --resolve and hosts edits work for a single human on a single machine. A proxy URL is a real, shareable browser URL — useful for full JS execution, third-party tag loading, Lighthouse, cookie/session flows, screenshots, and handing off to QA or the product owner.

Does it work with HTTPS origins?

Yes. The proxy connects to the new origin over HTTPS using SNI = production hostname so the origin selects the right TLS config. If the cert isn't valid yet (common pre-cutover), the proxy is lenient — separately verify the cert chain with our SSL Checker.

Can I integrate this into CI?

The preview URL is created via the web UI today. For headless CI checks, our individual free tools (DNS, SSL, redirect, security headers, HTTP headers) all accept GET requests with query parameters and return JSON — easy to script.

Does it support WebSockets and SSE?

Yes. The proxy upgrades Connection on demand and preserves long-lived connections. Useful for validating real-time features (chat, dashboards, notifications) on the new origin.

Related Guides & Tools

Don't cut over blind.

Spin up a preview URL bound to your new origin in 30 seconds. Validate the production routing path before flipping DNS.

Run Pre-Cutover Validation →