“The site is down” starts an investigation; it does not locate the failing layer. A small incident package with exact time, URL, response, change history and access route lets a technician begin safely without asking for secrets in chat.
Collect evidence without repeatedly triggering writes or exposing customer data.
Describe the symptom precisely
Record affected domain/URL, time with timezone, first noticed, frequency and who is affected.
Examples:
all pages return server-branded 502
wp-admin login loops but public pages work
one editor save returns REST 403
uploads above given dimensions return 500Avoid conclusions such as “database corrupt” unless logs prove it.
Capture HTTP evidence
Save status, redirect chain, relevant headers/request ID and a screenshot. Test root/www, HTTP/HTTPS and one static asset only as needed.
Do not include cookies, authorization headers, nonces or private query strings in HAR exports.
Redact before sharing; a full browser network archive can contain form/customer data.
Preserve logs around the time
Extract a narrow window from PHP, web server, MySQL and hosting resource events. Include the first fatal/error and call path.
Keep:
timestamp
error class/message
relative component path/line
request correlation ID
PHP/software versionRemove passwords, tokens, full database queries and personal content.
Document recent changes
List plugin/theme/core/PHP, DNS/SSL, cache/firewall, deployment, migration/import and hosting changes with exact time/operator/version.
“No planned change” is useful too; check automatic updates and provider maintenance.
Do not roll back multiple items before evidence is reviewed; that erases attribution.
Record hosting state
Capture disk/inodes, CPU/RAM/entry-process faults, PHP handler/limits, MySQL status and failed cron/backup events.
Use cPanel/Plesk/provider screenshots or exports that omit account secrets. Note whether other authorised sites/services on the account fail.
Do not run resource-heavy scans during an active overload.
Preserve evidence integrity
Save original log excerpts/screenshots with timestamps and checksums where incident or contractual review may matter. Work from copies and record any timezone conversion/redaction.
Do not edit the only original file to remove secrets; create a redacted derivative and protect the source with restricted access/retention. Note gaps caused by log rotation or unavailable systems instead of presenting assumptions as facts.
Define authority and stop conditions
State which systems are in scope and which actions are approved: read-only diagnosis, maintenance mode, plugin disable, database repair, DNS change or restore. Name the person who can approve downtime/data rollback.
Set stop conditions for uncertain payments, missing backups, evidence of data divergence or a destructive target that cannot be resolved exactly. Emergency urgency does not authorise deleting unknown data. This clarity lets the technician move quickly on reversible work and pause only where business authority is genuinely required.
Prepare access securely
Provide individual temporary/least-privileged panel/SFTP/SSH/WordPress access through an approved secret-sharing method, never in ordinary email/chat.
Confirm domain/document root and whether production changes are authorised. Enable audit logging and define expiry/removal.
Do not share the main hosting owner password when a scoped user works.
Confirm rollback assets
List backup timestamps, components (files/database/mail/DNS), storage location and last restore test. Do not claim “backup exists” without knowing whether it completed and is accessible.
Protect the pre-incident backup and take a current snapshot if safe. Avoid filling the failing disk with another archive.
Note data created since the last backup that must not be lost.
State business impact and constraints
Explain whether login, publishing, customer enquiries, checkout/email or only design is affected; provide traffic/deadline/maintenance constraints.
Identify external systems that must not be called from staging and who can approve downtime or rollback.
Keep revenue/customer numbers restricted to necessary recipients.
Package a reproducible handoff
Summarise symptom, one reproduction, evidence references, recent changes, access, backup and permission to act. Update it as facts change.
Recurring care should automate privacy-safe uptime/error/resource collection and maintain an access/backup inventory. Good evidence reduces diagnosis time while preserving the site state needed to make a confident repair.