Go-Live Readiness Check

Is a domain ready to launch or move? Checks DNS, propagation, SSL, HTTPS and domain expiry in one go and gives a ready, caution or not-ready verdict. Free.

Check it automatically in CI

Run the same check on every deploy and fail the job when the site misses your bar. Pick the bar, try it once now, then paste the address or the workflow step below into your CI.

API address for other CI systems (pass when data.pass is true)

GitHub Actions step (add after your deploy step — node-man/dechonet-gate)

Pro Keep watching after launch

Launch is just the start. DechoNet monitoring tracks SSL expiry, DNS changes, and security regressions automatically every day.

Learn about post-launch monitoring →

Related Guides

What is the Go-Live Readiness Checklist

Right before you launch a domain or migrate it to a new server or host, it checks five essentials for switching over: whether DNS resolves to an IP, whether the answer is consistent across 6 public resolvers, whether SSL/TLS is ready, whether the site is reachable over HTTPS, and whether the domain registration is not about to expire.

How it works

It runs DNS, propagation across 6 public resolvers, SSL, HTTP and RDAP checks in parallel. Missing resolver replies or unverified TLS connection, served certificate expiry or chain trust mean "Caution"; CT issuance alone cannot pass TLS. Failed prerequisites mean "Not Ready". Only five observed, passed checks mean "Ready".

FAQ

How long does DNS propagation take?

There is no fixed propagation deadline. Cached answers can remain until their TTL expires. Different answers can also be intentional with GeoDNS or a CDN, so disagreement alone does not prove an unfinished change. Compare the answers with your intended records and re-check after the old TTL.

Does "Ready" mean it is 100% safe?

This checklist verifies the technical prerequisites for switching over (resolution, propagation, TLS, reachability, valid domain). It does not vouch for your application logic, content, or performance — test actual functionality separately.

When should I use it during a migration?

Run it right after pointing DNS at the new server to confirm propagation consistency and the new server's TLS/HTTPS readiness. "Ready" means the five external prerequisites passed from our observation points; test the application itself separately.