How Core dna caches pages, what makes a render fast, how code reaches a site and what stays behind, the go-live checklist, and running a site once it is live. For developers, leads and site operators who already build pages in a theme repository.
L2–L3
Unit 05 · Go-live
Launch-day monitoring
Go-livePage 28 of 34Updated
The first hour after the DNS switch decides whether a launch is a launch or an incident. What to watch, where to watch it, who watches what, and the thresholds that mean roll back rather than fix forward.
Who this is for. The team on duty when a site goes live, and the person named to decide on rollback. Afterwards each signal has an owner, a place to read it, a frequency and a number that means act.
On launch day the team's attention is on the switch itself, and the first problems arrive just after it, when everyone has relaxed. Decide beforehand who watches each signal below, how often, and what number means act. Then a decision to roll back, if it comes, is taken on evidence by the person named for it, not argued about while customers wait.
First: warm the cache
The launch-day cache clear leaves every page to be rendered by its first visitor. Request the most-visited URLs once yourself, signed out, so that real visitors find them stored. Only anonymous GET requests that answer 200 are stored, and only in production mode:
Shellwarm-cache.sh
while read -r path; do
curl -s -o /dev/null -w "%{http_code} %{time_total}s $path\n" "https://www.example.com$path"
done < top-urls.txt
Take top-urls.txt from the old site's analytics: the hundred most-visited pages and every page linked from the main navigation. The output is also the first health check of the hour: every line should be 200, and a second run should be much faster than the first.
What to watch, and where
Signal
Where
How often
Act when
Errors
The admin's Template Errors screen, for the site, over the last hour (reading the error log)
Every 10 minutes
Any error on a main page type, or the same error repeating
Availability
An uptime check on the home page, a product or article, the cart and the search page
Every minute, automated
Any 5xx, or two failed checks in a row
Checkout completions
New orders in the admin, and the payment provider's live dashboard
Every 15 minutes
No orders over a period in which the old site always had some, or declines above the usual rate
The redirect map
The redirect test script, then the not-found page in real-time analytics
Once after the cache clear, then every 15 minutes
Any failing entry, or more than 1% of page views landing on not found
Forms and mail
A test submission of each main form, read where it is delivered, and the email's status in the Mailer batches
Once, early
A submission not saved, or a notification not sent
Compare checkout numbers with the old site at the same hour and weekday, not with a guess. A quiet hour on a Tuesday morning is normal; no orders through a usually busy hour means treating the checkout as down until proven otherwise. The thresholds here are starting points: agree your own with the client before the day.
Fix forward or roll back
Fix forward when the fault is contained and understood: an unstyled section, a bad link, a missing redirect, an error on a minor page. Release the hotfix and keep watching (hotfixes).
Roll back when visitors cannot do the main thing the site exists for (buy, book, sign in, apply) and the fix is not known within 30 minutes; when the site is unavailable for more than a few minutes; or when money or personal data is at risk. How far back depends on what failed (the decision procedure).
Write the thresholds into the launch plan with the name of the person who decides, and keep the old site running and the DNS time-to-live short until the first day is over.
After the first hour
Check the same signals at the end of the day and every morning for the first week: template errors, not-found pages, orders against the old site's numbers, and the search console's crawl errors (before-and-after checks). Most launch problems that survive the first hour are found by these daily reads, not by monitoring.