Auditing a site

The person says: “Check the venue site is OK; something looked off this morning.”

Every step here is a read. The answer is a short report a support person could act on without watching the session.

The loop

1. Empress:whoami — the site’s slug, the person’s role, and the plan’s allotments.
2. Empress:site_status — live against staged, the open change set, the versions (what changed and who did it), traffic, the theme in short, and health: the last check’s verdict in a sentence, the day’s errors, the newest deployment and the newest build of the theme.
3. When a page errors or health is failing, through Empress:site_call (each a read):
   • empress.site_issues — the errors grouped by what they say, most frequent first.
   • empress.site_traces with path (or a requestId from a log line) — what that request answered, the step that failed and the log line it wrote.
   • empress.site_logs with level: "error", filter or path — the plain log lines, newest first.
   • empress.site_deployments and empress.site_versions — what changed on the Worker, and when.
   • empress.site_health — check now; the verdict lands in site_status.
   • empress.site_platform — where the Worker answers from, where its data lives, whether pages are edge-cached; read it when site_status says the platform layer has not been read, or the site is slow.
   • empress.site_db_query — one SELECT against the site’s own database, when the content itself is in question.
4. When a build failed or is running: Empress:site_status with section: "builds" — the theme’s builds, newest first, how each ended, the phase a failure stopped at and its sentence, and which one the site serves. Then, through Empress:site_call, empress.build_log with the build’s buildId — its last lines, or search for a word the failure names; a running build is followed with Empress:work_status and its id.
5. Empress:site_preview — target: "live" at three widths, with probes: { layoutShift: true }; then the paths the person named.
6. Empress:content_query — the content the person is asking about, with its live and draft revisions.
7. Empress:search — anything the audit needs that is not listed (forms, plugin tools), by what it does.

Judgment

• Report what is, then what changed. Lead with what visitors get now, then the newest versions entries, then traffic against the window before.
• A 4xx or 5xx at any width is the headline. Say which page, what it answered, when, the failing step and the log line, in that order; the request id is the one id worth quoting.
• A failed build is not a broken site. The site keeps serving the build marked live; say which phase failed, its sentence and the log line that names it.
• A draft that differs from live is unfinished work, not a fault.
• Fixing is a separate request. End with the next step and let the person choose it (see staging-a-change, recovering-from-a-mistake).