Outage repair or malware cleanup?
A failed update and a compromised website can produce similar errors but require different handling. If there are unexpected users, redirects or malicious files, preserve evidence and assess the incident before overwriting the site. For an ordinary outage, we compare the cost and data impact of a targeted fix with restoration. Availability and timing are confirmed after initial review.
Diagnose downtime before choosing a restore
DNS, TLS, hosting, application errors and compromise can all make a site unavailable. Record the first failure time, affected functions, recent changes and business impact before changing systems. A blank screen does not establish malware.
- Preserve error details and available logs.
- Identify the failing layer and authorized access.
- Compare recovery options with newer data.
- Repair and test the customer journey.
Choose recovery by the failing layer
Major incident recovery, full forensic investigation and data reconstruction are not implied by a starting estimate. Confirm eligibility and scope first. Compromise symptoms need entry-path and access review rather than repeated restoration of the same vulnerable state.
| Observation | Next check | Boundary |
|---|---|---|
| No resolution | DNS authority and records | Application restore may be irrelevant |
| Error after update | Runtime/application logs | Rollback must consider data |
| Unknown administrator | Preserve evidence | Compromise assessment may be needed |
Example: preserve orders during an update rollback
A store fails after an update. Recovery options are compared with orders created since the backup, then checkout is tested after the approved repair. This is an illustrative scenario, not a customer case or a promised result.