Why websites go down: the failures we see first

This article is the experience companion to our emergency website repair page. If the site is down right now, call or send the URL. If you have ten minutes, walk the checklist below before anyone “just updates everything.”

The short list

Availability and runtime errors are the obvious ones: a white screen, a fatal, an intermittent 500, a storefront that stopped loading after “nothing changed.” Something always changed. The host moved PHP. A plugin auto-updated. A redirect rule was saved with a typo. The disk filled up. Memory ran out on a page that used to be cheap.

We have brought sites back after a hosting-side runtime upgrade left installed plugins incompatible. We have recovered a Magento admin that fatal-errored on generated metadata and compiled files. We have seen a development copy die because someone saved malformed redirect syntax. We have seen a public site stop on memory exhaustion and still have a leftover plugin-activation problem after it loaded again. None of those required a redesign. All of them required a snapshot first.

There is a second pattern that wastes a day if you start in the wrong place: visitors cannot reach the storefront, and the administration interface still works. That split is often DNS, cache, or a registrar putting obsolete nameservers back. The CMS cannot fix a nameserver reversion. We have handed that exact case back to the registrar path and left the outcome open in the notes rather than pretend the homepage returned because we edited a template.

First 15 minutes

Write down the visitor symptom, the time it started, and the last change you know about. Confirm whether the failure is public pages, admin, checkout, forms, or everything. Then preserve a recoverable copy: a hosting snapshot, an off-site backup, or a file-and-database dump if that is all you have.

Check DNS and SSL before you guess at code. Check the host: disk, runtime, error log, process or App Service status. If admin is gone, recover the safest control point — host panel, SFTP, or the registrar — before you repair. Apply the smallest safe fix. Validate as a visitor, including a phone-sized browser. Write three lines: what broke, what you changed, what is still open.

The printable version lives on the emergency page as our site-down triage checklist. Use it. Do not improvise a deploy over a site you have not copied.

When the host upgraded PHP

This is one of the most common honest sentences we hear: “We did not change anything. The host did.” A newer runtime is a change. Plugins that were merely unmaintained become fatal. Compiled files in Magento become stale. A WordPress site that “only needed an update” becomes a white screen because the update and the runtime moved on the same weekend.

The repair is: identify the incompatible components, restore the public site, and tell the owner which pieces cannot follow. Silently rolling the host back without saying so is how the same outage returns on the next mandatory upgrade.

When it is not a bug

Spam pages, unexpected redirects, new admin users, or files that return after you delete them are an incident. Triage can start on the emergency page; the cleanup itself is scoped on WordPress malware removal. We have seen cleanups during a deploy reinfect because the entry point was never closed. That is why we treat an incomplete cleanup as a risk, not a finished job.

Read the log before you touch the theme

A generic “there has been a critical error” screen is a cover. The useful sentence is in the recovery-mode email, wp-content/debug.log, or the host error log. The file path tells you whether you are looking at a plugin, a theme, core, or the runtime. Renaming a theme folder because the homepage is white is how you add a second outage to the first. We wrote a longer recovery path for that exact WordPress message in the critical error guide; the emergency page is for when you want someone else to run it.

The same discipline applies outside WordPress. A Magento admin fatal that names generated metadata is a compile/cache job. A Node process that exited is a host job. A Laravel 500 that points at a database connection is not a CSS job. If you cannot read the log, recover SFTP or the panel first. If you cannot recover the panel, you do not have an application incident yet — you have an access incident.

The host is in the room

We repair sites on Azure, AWS, Linux VPS, Windows/IIS, cPanel, Plesk, dedicated machines, and ordinary shared hosting. A lot of emergencies sit in the gap where hosting support says “application” and the application vendor says “hosting.” Sitting in that gap is the job. Disk full, inode limits, a restarted PHP-FPM pool, an expired App Service certificate, a Cloudflare proxy that still points at a decommissioned origin — none of those are theme work.

When we ask for access, we are asking for the shortest path to that gap: CMS or app admin, the host or cloud panel, SFTP/SSH or RDP, the registrar or Cloudflare, and a sentence about the last change. Missing access is not a reason to start guessing. It is the first repair.

After the homepage returns

Forms and mail often fail in the same window and nobody notices until the next lead should have arrived. Check a form send. Check checkout if you have it. If the same fault comes back within 30 days of a Metro Vancouver IT repair, we fix that fault again at no charge — the one we were hired for, not a new one.

If you want someone else to run that first pass, send the URL. If you want the longer maintenance rhythm so the next PHP bump is scheduled, see WordPress care. The same first-15-minutes list is printed on the emergency page so you do not have to hunt for it during an outage.

How we actually run this from Burnaby

Metro Vancouver IT is a small shop. The person who answers the phone is the person who opens the logs. Routine work is remote across Canada. On-site visits stay inside Metro Vancouver and only when hands-on work is required. We do not promise same-day dispatch in another province, and we do not pretend a Slack bot is a technician.

Emergency repair is billed at $90 CAD/hour. Most jobs land in a two-to-three hour window; we confirm an estimate before billable work starts. If the same fault returns within 30 days, we repair that fault again at no charge. A new fault is a new conversation. We will tell you which one we think we are looking at.

If you want the work in a care plan instead of an emergency, that is the point of website maintenance and managed WordPress hosting with daily off-site backups. Backups you have never restored are rumours. Ask for a restore test before you need one.

What we will not claim

We will not invent a resolution-time SLA from tickets that do not have a reliable resolved-at field. We will not publish agency-era counts as Metro Vancouver IT results. We will not tell you the site is clean because a scanner said so while files still come back. We will not tell you mail works because a thank-you page rendered. Those refusals are the unique value. Anyone can generate a long page about outages. A useful page names the first checks, the incomplete outcomes, and the price you will actually be asked to approve.