toolkit

Scenario · Before you touch a site

Is every client site still ours, and still up?

The monthly sweep across the whole portfolio — nobody reported anything, which is the point.

The monthly sweep across an entire portfolio of client sites exists to beat the client to the phone — finding the site that's been down since Saturday, or the one that quietly moved to another host, before the practice notices and calls. This checks every domain at once: whether it's still hosted where it should be, whether the home page actually loads with its basics intact, and whether pending updates are piling up unnoticed. It's deliberately shallow across many sites rather than deep on one, because that's the only way a check like this actually gets run every month.

What to ask for

Provider roster checkProvider roster check — compares the people a site publishes against the roster of who should be there.MainWP fleet clientOptional integration — reads a MainWP dashboard's fleet: every managed WordPress site, pending core/plugin/theme update counts, and connection health.WP Engine install clientOptional integration — reads which WP Engine install serves a domain: which install (and whether it is production/staging/dev), every domain attached to it, its PHP version, and its backup points.Hosting & DNSHosting & DNS infra fingerprint — reads a domain's DNS, TLS, headers and RDAP and reports the backend stack: web host, nameservers, CDN/edge, email provider, SSL issuer, CMS, registrar and last-changed date.Critical-path smoke testCritical-path smoke test across every domain at once.

See it work

A real run of Critical-path smoke test:

FAIL  1 FAIL · 0 REVIEW · 0 BLOCKED · 0 PASS

  FAIL   toolkit-tests.pages.dev
         [error] the home page returned HTTP 200 but rendered only 1 characters of text — effectively blank
         [warn] no <nav> or role="navigation" on the home page — the primary menu may be gone
         [warn] no tel: link on the home page
         [warn] no form or booking widget in the delivered HTML — this check does not run JS, so a script-injected form would not be seen

  report: ./out/critical-path-smoke-test-critical-path-smoke-test.html
  text:   ./out/critical-path-smoke-test-critical-path-smoke-test.txt

The captured report, exactly as a run hands it to a client —open the full report ↗

The sweep that beats the client to the phone. Its whole value is frequency: run monthly it finds the site that quietly moved hosting, the one that has been down since Saturday, and the twelve carrying plugin updates nobody applied.

  1. Check the roster against reality. The provider roster check compares what we believe about each domain’s hosting against what its DNS actually says. A live client who moved to another provider — or a former client still pointed at us — is the finding that costs money in both directions.
  2. Smoke-test every domain at once. The critical-path check confirms per site that the home page loads and is not a fatal error, a parked placeholder or a blank screen, and that the nav, a dialable phone link and a form or booking widget are present. One request per page, no browser: breadth over depth, deliberately.
  3. Lead with what changed. Run the smoke test against the previous run’s state so the report starts with the sites that moved rather than a list of two hundred passes. A sweep whose output is unchanged is a sweep nobody reads.
  4. Pull the fleet’s update position. The dashboard client reports every managed site with its pending core, plugin and theme update counts and its connection health. A site that has dropped off the dashboard is not a site with no updates — it is a site nobody is watching.
  5. Spot-check hosting where the roster disagreed. For any domain step 1 flagged, read its DNS, TLS and registrar detail, and where relevant confirm which install actually serves it and whether that install is production or staging. A domain pointed at a staging install is a live client site serving the wrong content.
  6. [manual] Triage the exceptions into real tickets. Down sites first, then hosting mismatches, then update backlogs. Each becomes its own scenario; this sweep only finds them.
  7. Keep the run. The comparison in step 3 only works if the previous state was kept.

Breadth is the feature, not a limitation

Every check here is deliberately shallow, because the alternative — a deep audit per site — cannot be run monthly across a portfolio and so does not get run at all. The failure mode this catches is not a subtle defect; it is a site that has been broken for five days and nobody knew.

What this does not cover

Anything requiring a look at one site properly. This is breadth: it answers "which of these needs attention" across a portfolio and nothing about why. A site that loads, is on our servers and has no pending updates can still be broken in every way that matters to the practice paying for it.

← All scenarios