Guide 12 · Developer docs

Performance, caching, deployment and go-live

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 06 · Running a site after launch

Health checks worth automating

Running a site after launch Page 33 of 34 Updated

The recurring checks that find a problem before a customer reports it, how to run each from outside the site, and the threshold at which each one should alert someone.

Who this is for. Whoever owns a live site's operations, at the agency or the client. Afterwards you have a list of checks, each with a method, a frequency and an alert threshold, and two of them as scripts.

Most failures on a live site are quiet: a scheduled export that stopped, a certificate about to expire, a payment method switched back to Test Mode, search that finds nothing. None of them shows on the home page, so none is caught by checking the home page. Most checks below run from outside the site; the few that need the admin say so. Each has a threshold, so that it alerts when it should and not otherwise.

The checks

CheckHowHow oftenAlert when
AvailabilityRequest the home page, a product or article, and the cart, signed out, and check the status and a piece of textEvery minuteTwo failures in a row, or any 5xx
Search worksSearch for a word certainly on the site, such as the client's name, and look for the zero-result message (when search fails)Every 15 minutesThe zero-result message appears
Scheduled jobs ranEach scheduled job calls a heartbeat service as its last action (monitoring scheduled work)Each job's scheduleA call more than one interval late: 26 hours for a daily job
Background work keeps upRead the admin's background tasks (/cdna-admin/admin/jobs) for tasks still waiting, or ending in errorDaily, by a personTasks waiting for more than 30 minutes, or the same task in error twice
CertificatesRead the expiry date of each hostname's certificateDailyFewer than 21 days left
No test payment methodsThe payment methods check (the check that none is selectable)DailyAny output
Payment providerThe provider's status page, and its own alerts for failed webhooks and unusual declinesContinuous, by the providerAny alert
RedirectsThe redirect test over the whole map (testing every entry)Daily in the month after launch, then weeklyAny failing entry
SitemapRequest /sitemap.xml. A 202 means a rebuild has just been queued, which is normal onceDailyNot 200 with content on two checks an hour apart
Mail is deliveredSubmit a test through the main form to a monitored inboxWeeklyThe notification does not arrive within 15 minutes

Read template errors daily for the first month after launch and weekly after that (Reading the error log).

Two of them as scripts

Certificate expiry, for each hostname:

Shell cert-days.sh 
#!/bin/sh
# cert-days.sh www.example.com example.com shop.example.com
for host in "$@"; do
  end=$(echo | openssl s_client -servername "$host" -connect "$host:443" 2>/dev/null \
        | openssl x509 -noout -enddate | cut -d= -f2)
  days=$(( ( $(date -d "$end" +%s) - $(date +%s) ) / 86400 ))
  [ "$days" -lt 21 ] && echo "ALERT $host certificate expires in $days days"
done

Search, from outside. The search page's address is /search/ followed by the search view's slug, and the zero-result text is whatever your template prints:

Shell search-alive.sh 
#!/bin/sh
# search-alive.sh
curl -s "https://www.example.com/search/site-search?q=Example" | grep -q "Nothing found for" \
  && echo "ALERT search returns nothing for a term that is on the site"

Run them from a monitoring service or a scheduled CI job, not from a laptop, and send alerts to a shared channel with a named owner for each check.

Choosing thresholds

A check that alerts too often is muted within a week, and a muted check is worse than none, because everyone assumes it is watching. Alert on two failures, not one, wherever a single blip is normal; alert on absence (a call that did not arrive) rather than presence for scheduled work; and review the thresholds after the first month, when you know what normal looks like for this site. The numbers above are starting points, not platform limits.

Go deeper
GuideScheduler tasks and the job queue GuideWhere the logs are FAQA scheduled job stopped running and nobody noticed FAQA new record does not appear in search

Was this page helpful?

Your answer goes to the docs team.