Skip to content
Metro Vancouver IT Metro Vancouver IT
Skip visual story

01 / 06 Website down

Emergency website repair

Urgent help when a business website or store is down, broken after an update, or blocking orders — on almost any CMS, stack, cloud, or web host.

  • Most repairs total $180–$270 — that is 2–3 hours at $90 CAD/hour, and we confirm an estimate before billable work starts
  • Same-day triage for broken, unreachable, or compromised sites and stores
  • 30-day re-fix: if the same fault comes back within 30 days, we fix it again at no charge

02 / 06 Critical functions failing

Keep orders and enquiries moving

We trace business-critical failures from the visitor action to the system that should receive it, then repair the smallest safe point of failure.

  • Checkout, payments, shipping, product pages, and order emails
  • Contact, quote, and booking forms — including SMTP and notification routing
  • Admin, login, search, cron, and API failures after updates or package changes

03 / 06 Infrastructure or security failure

Prove where the fault lives

When the host says “application” and the vendor says “hosting,” we check both sides and show which layer is actually broken.

  • DNS, SSL, Cloudflare, redirects, certificates, and domain cutovers
  • Azure, AWS, Google Cloud, Linux or Windows servers, VPS, cPanel, Plesk, and shared hosting
  • Injected spam, rogue redirects, backdoors, compromised admins, and recurring files
See the full WordPress malware removal scope

04 / 06 Diagnose before editing

Start with evidence, not guesses

We stabilize the decision-making first so an urgent edit does not turn one fault into three.

  • Triage: confirm the symptom, business impact, recent changes, and available access
  • Snapshot: take a fresh backup or hosting snapshot where possible before risky changes
  • Check first causes: logs, runtime, disk, DNS, SSL, recent changes, delivery, and database connectivity

05 / 06 Isolate, repair, validate

Make the smallest safe fix

The repair is only complete when the affected journey works for a real visitor, not merely when the admin screen looks calm.

  • Rollback, patch, disable a conflict, restore a file, remove malware, correct DNS, renew SSL, or repair mail routing
  • Keep the fresh-backup principle in place wherever access allows
  • Validate affected pages, forms, checkout, login, SSL, redirects, and mobile views

06 / 06 Restored and verified

Working again, with a clear next step

The same technician handles triage, repair, and notes, then recommends only the maintenance, hosting, backup, monitoring, or hardening that directly reduces repeat risk.

  • Plain-English repair notes so the next person can see what changed
  • 30-day re-fix coverage for the specific fault we repaired
  • No call-centre handoff and no forced migration to sell you hosting

Our promise

30-day re-fix guarantee

If the fault we repaired comes back within 30 days, we repair it again at no charge. It applies to the problem we were hired to fix — not a new, unrelated failure — and we say plainly which of the two we are looking at.

  • An estimate you approve before any billable repair work begins
  • If the scope changes mid-repair, we stop and confirm the next step with you
  • Repair notes in plain English, so the next person can see what changed

What you get

How Emergency website repair actually works

We stabilize the live site first, then tell you what broke and what to do next. WordPress is common — it is not the limit.

Down or broken site

HTTP 500 errors, white screens, failed updates, broken layouts, redirects, and checkout or login problems on any CMS or app.

Any CMS or web app

WordPress, Drupal, Joomla, Sitefinity, Squarespace, Wix, Laravel, Node.js, custom PHP, and other stacks we can reach and diagnose.

Ecommerce stores

WooCommerce, Shopify, Magento, BigCommerce, and PrestaShop: carts, payments, shipping, product pages, and order emails.

Forms not sending

Contact forms, SMTP, DNS records, spam filtering, and notification routing checked from form submit to inbox.

DNS & SSL issues

Expired certificates, mixed content, redirect loops, DNS changes, Cloudflare settings, and domain cutover problems.

Malware & compromise

Injected spam, rogue redirects, backdoors, and hacked admin accounts. We triage the emergency here; full cleanup and hardening runs on our dedicated page.

WordPress malware removal

From experience

What usually takes a site down

From our team’s years of agency support work, emergency calls cluster around a short list of failures. We start there instead of rebuilding the site on day one.

  • Runtime or availability errors

    White screens, fatals, intermittent 500s, or a site that stopped loading after nothing “changed” on the business side.

  • Hosting-side changes

    A PHP or runtime upgrade, a disk filling up, or a rewrite rule the host applied overnight.

  • Update incompatibility

    A plugin, theme, or compiled file that does not survive the last update.

  • Admin and public site diverging

    Storefront down while wp-admin or the Magento backend still loads — often DNS, cache, or nameservers, not the CMS.

  • Memory, redirects, and databases

    Exhausted memory, malformed redirects, or a database that will not answer.

  • Forms and mail riding along

    The outage is the emergency; the silent mail failure is what you discover after the homepage returns.

From experience

Situations our team has handled

Anonymized examples from recent support work (2025–2026). Incomplete outcomes stay incomplete — we do not invent a clean ending.

2026

Site down after a host runtime upgrade

What they saw
The public website stopped working after the host moved the account to a newer runtime.
What we found
Installed plugins were incompatible with the new runtime.
What we did
We isolated the incompatible plugins, restored the public site, and re-enabled the event functionality the business needed that week.

2026

Magento admin showed a fatal error

What they saw
Administrators hit a fatal error as soon as they opened the backend.
What we found
Generated metadata and compiled application files were in a bad state. The ticket never named a single initiating change.
What we did
We rebuilt the generated files and confirmed the backend loaded again.
What stayed open
The original trigger was not recorded.

2026

Malformed redirects took a site offline

What they saw
A development copy showed errors and later became unreachable.
What we found
Hosting support traced the later outage to malformed redirect syntax.
What we did
The redirect rules were corrected and the site was reported back online.

2026

Public site stopped on memory exhaustion

What they saw
The public website stopped loading.
What we found
Error inspection pointed at memory exhaustion.
What we did
The site was brought back online.
What stayed open
A separate plugin-activation issue remained after the outage was cleared.

2026

Storefront down, admin still working

What they saw
Visitors could not reach the storefront. The administration interface still loaded.
What we found
Registrar settings were reverting to obsolete nameservers.
What we did
We identified the reversion and handed the correction to the registrar path the client already had open.
What stayed open
Final public restoration was not documented in the notes we kept.

Rewritten from internal notes. No client names. Dated in the current 2025–2026 window.

First 15 minutes

Site-down triage checklist

Do these in order before anyone edits production. Print or save this page if you want a copy beside the keyboard.

Print this page to keep a paper copy beside the work.

  1. 1 Write down the exact visitor symptom, the time it started, and any change in the last 48 hours (plugin update, PHP bump, DNS edit, deploy).
  2. 2 Confirm whether the failure is public pages, admin, checkout, forms, or everything.
  3. 3 Preserve a recoverable copy first: hosting snapshot, off-site backup, or a file-and-database dump if that is all you have.
  4. 4 Check DNS and SSL before guessing at code: nameservers, A/AAAA/CNAME, certificate expiry, redirect loops, Cloudflare proxy.
  5. 5 Check the host: disk full, runtime version, PHP error log, process crash, App Service or VM status.
  6. 6 If the site still has admin, do not update anything yet. If admin is gone, recover the safest control point (host panel, SFTP, or registrar) before repairs.
  7. 7 Apply the smallest safe fix: rollback the last change, disable one conflict, restore one file, correct DNS, or renew SSL.
  8. 8 Validate as a visitor: homepage, an interior page, login, a form, checkout if you have one, and a phone-sized browser.
  9. 9 Write three lines: what broke, what you changed, what is still open.

This is the sequence we use on emergency repairs. It is not a service-level promise.

Verified Metro Vancouver IT work

Related case studies

Named clients, with consent, from work we delivered as Metro Vancouver IT.

All case studies
Kits Inflatables

Marine retail · Richmond

Kits Inflatables

Managed WordPress hosting and search engine optimization for a long-running inflatable boat and marine accessories business.

Website launch
Completed
Hosting
Managed WordPress
SEO foundation
Technical + local signals
NuGlass

Glass manufacturing · BC

NuGlass

A hacked website recovered and stabilized with ongoing WordPress hosting and uptime support — in a case where no backup was available.

Recovery
Restored from scraped content
Hardening
WAF + admin lockdown
Backups going forward
Daily off-site, tested

Not only WordPress

We repair the site you actually run, on the host it already lives on

WordPress emergencies are frequent, so they show up in our examples. The repair work is not limited to WordPress. If the site is Drupal, Joomla, Sitefinity, Squarespace, Wix, a Shopify or Magento store, WooCommerce, a Laravel or other PHP application, a Node.js app, or a custom CMS, we still start the same way: confirm what visitors see, find whether the failure is DNS, SSL, hosting, code, database, checkout, or malware, then apply the smallest safe fix.

The same is true of the platform underneath. We work on Microsoft Azure, Amazon Web Services, Google Cloud, managed and self-managed Linux VPS, Windows Server and IIS, cPanel and Plesk accounts, dedicated servers, and everyday shared web hosting. Hosting support saying “it is an application problem” while the application vendor says “it is hosting” is a normal starting point — we sit in the middle and prove which side is actually broken.

When the symptoms look like a hack — spam pages, unexpected redirects, new admin users, blacklists, or files that keep coming back — we treat it as an incident rather than a bug. Triage still starts here, and the cleanup itself is scoped on our WordPress malware removal page: snapshot first where access allows, remove the malware, close the entry point, and leave you with plain-English notes instead of a mystery restore.

Access that helps us move quickly

The fastest repair path usually needs CMS or app admin, hosting or cloud panel (cPanel, Plesk, Azure, AWS, or similar), SFTP/SSH or Windows RDP when available, DNS registrar or Cloudflare access, and any recent change history. If access is missing or compromised, we start by helping recover the safest control point.

Platforms we repair

CMS, stores, and hosting we actually work on

If it is a website or store we can reach, we will triage it. These are the stacks we see most often — not a closed list.

WordPress & WooCommerce

White screens, critical errors, plugin conflicts, checkout failures, and admin lockouts.

Shopify, Magento & BigCommerce

Broken carts, payment apps, shipping rules, theme errors, and order notifications that stopped sending.

Drupal, Joomla & Sitefinity

Module conflicts, failed updates, login issues, and sites stuck after a vendor or PHP change.

PHP, Laravel & Node.js

Fatal errors, database connection failures, process crashes, and legacy code that still has to take orders today.

Azure, AWS & Google Cloud

App Service, VMs, load balancers, certificates, DNS, and resource limits that take a site offline.

Linux, Windows & any web host

VPS, dedicated, cPanel, Plesk, IIS, and shared hosting — we diagnose the box before guessing at the app.

Symptoms we fix

A strong fit when

  • The website is down, showing a fatal error, or stuck after an update — on WordPress or any other CMS
  • A contact form, quote form, booking form, or checkout stopped sending notifications
  • SSL, DNS, redirects, Cloudflare, or a host/cloud change made the site unreachable or insecure
  • Admin, checkout, cron, search, or APIs stopped working after a plugin, module, or package change
  • The site looks hacked: spam content, redirects, malware warnings, or files that keep coming back
  • Hosting support says it is an application problem and the application vendor says it is hosting

Our process

How emergency repair works

The goal is to stabilize the site first, then leave you with a short list of what changed and how to prevent the same failure.

  1. 1

    Triage

    Confirm the symptom, business impact, recent changes, and available access. We identify whether the first move is hosting, DNS, SSL, CMS, code, database, or malware.

  2. 2

    Snapshot

    Take a fresh backup or hosting snapshot where possible before making risky changes, even if the current state is already broken.

  3. 3

    Check first causes

    Review logs, runtime version, disk space, DNS, SSL, recent CMS or package changes, form delivery, and database connectivity before editing production.

  4. 4

    Repair safely

    Apply the smallest fix that stabilizes the site: rollback, patch, disable a conflict, restore a file, remove malware, correct DNS, renew SSL, or repair mail routing.

  5. 5

    Validate

    Test the affected pages, forms, checkout, login, SSL, redirects, and mobile views so the fix is real for visitors, not just visible in admin.

  6. 6

    Prevent repeat issues

    Provide plain-English notes and recommend maintenance, hosting, backups, monitoring, or security hardening only where it directly reduces repeat risk.

Metro Vancouver IT technician at Fisherman’s Wharf in Steveston, British Columbia

Who does the work

You deal with the person doing the repair

Metro Vancouver IT is a small Burnaby-based shop, not a ticket queue. The person who triages your site is the person who repairs it and writes your notes — no handoffs to a call centre, no offshore night shift guessing at your host.

  • Phone and email go to the same technician throughout the repair
  • We work on your existing host and CMS — no forced migration to sell you hosting
  • On-site in Metro Vancouver when it genuinely helps; remote everywhere else in Canada

CMS, stores, and platforms we repair

  • WordPress WordPress
  • Drupal Drupal
  • Joomla Joomla
  • Sitefinity Sitefinity
  • WooCommerce WooCommerce
  • Shopify Shopify
  • Magento Magento
  • BigCommerce BigCommerce
  • PrestaShop PrestaShop
  • Squarespace Squarespace
  • Wix Wix
  • PHP PHP
  • Laravel Laravel
  • Node.js Node.js
  • Microsoft Azure Azure
  • AWS AWS
  • Linux Linux
  • Windows Windows

Related services

Pairs well with

Maintenance & support

Ongoing updates, monitoring, and rapid fixes.

Learn more

PHP & legacy website support

Older PHP, databases, and custom CMS troubleshooting.

Learn more

Sitefinity support

Sitefinity troubleshooting, export, and migration planning.

Learn more

Why websites go down

The short list of failures we look at first, and the first-15-minutes checklist.

Learn more

FAQ

Frequently asked questions

Do you only repair WordPress?
No. WordPress is common, but we also repair Drupal, Joomla, Sitefinity, Squarespace, Wix, Shopify, WooCommerce, Magento, BigCommerce, PrestaShop, Laravel and other PHP apps, Node.js apps, and custom CMS builds. If we can reach the site, we will triage it.
Which hosting platforms do you work on?
Azure, AWS, Google Cloud, Linux VPS, Windows Server / IIS, cPanel, Plesk, dedicated servers, and ordinary shared web hosting. The emergency is often between the app and the host, so we check both.
Can you remove malware from a hacked website?
Yes. We snapshot first where access allows, remove injected files and database junk, close the entry point, rotate compromised access, and give you a short hardening list. If the site is a hacked WordPress install, the full scope — including Search Console and blacklist reconsideration requests — is set out on our WordPress malware removal page at /services/hacked-wordpress-website-cleanup. The same incident process applies to other CMS and PHP sites.
Can you fix a broken Shopify or WooCommerce store?
Yes. We repair WooCommerce, Shopify, Magento, BigCommerce, and PrestaShop issues: checkout, payments, shipping, product pages, apps/plugins, and order emails. Shopify is a hosted platform, so we work on the theme, apps, DNS, SSL, and storefront code we can reach — not Shopify’s own core.
How quickly can you start?
Same-day triage is often possible for urgent website problems. The exact start depends on access, severity, and whether hosting or DNS control is available.
How much does emergency website repair cost?
Emergency website repair is billed at $90 CAD/hour. Most repairs take two to three hours (about $180–$270), but it always depends on the case. We confirm a time estimate to approve before billable repair work begins. If the scope changes, we pause and confirm the next step.
Do you need admin access?
Usually yes. CMS or app admin, hosting or cloud panel, SFTP/SSH or Windows RDP, DNS registrar or Cloudflare, and recent change history help us repair faster. If credentials are missing, we start with the safest access recovery path.
Can you fix contact forms that stopped sending email?
Yes. We check form settings, SMTP, SPF, DKIM, DMARC, spam filtering, and notification routing so form submissions reach the right inbox.
Will you make a backup first?
Where access allows, yes. We prefer a fresh backup or snapshot before repair work, especially if the site is partially working or the root cause is not obvious yet.
What happens after the emergency is fixed?
You get concise repair notes and prevention recommendations. Many clients then move to maintenance, managed hosting, monitoring, or security hardening so the same issue is less likely to return.
What if the same problem comes back?
If the fault we repaired returns within 30 days, we fix it again at no charge. That covers the specific problem we were hired to fix, not a new or unrelated failure, and it assumes nobody else changed the site in the meantime. We will always tell you plainly which of the two we think we are looking at.
The public website stopped loading. Where do you start?
We confirm what visitors see, then check DNS, SSL, hosting runtime, error logs, and the last change before we edit production. Memory exhaustion, a host PHP upgrade, and a malformed redirect are all on that first pass.
The site broke after the host upgraded PHP. Can you put it back?
Usually. We identify which plugins or compiled files are incompatible with the new runtime, restore the public site, and tell you which components cannot follow the upgrade. We do not silently roll the host back without you.
Visitors cannot reach the storefront but admin still works. Is that a CMS failure?
Often not. That split is a classic DNS, cache, or nameserver problem — including a registrar putting obsolete nameservers back. We check those before rewriting the store.

Need emergency website help?

Tell us the URL, what broke, and what access you have. Most repairs total $180–$270 — 2–3 hours at $90 CAD/hour — and we confirm an estimate before billable work starts. WordPress, Drupal, Joomla, Shopify, WooCommerce, Magento, or any host.

Contact

Tell us what broke

Include the website URL, the exact symptom, when it started, and what access you have. Urgent requests are triaged the same business day when received during Pacific Time business hours.

Hours
Mon–Fri · 9:00 AM – 6:00 PM (PT)

Add any details that will help us understand what you need. Maximum 600 characters.

Typical first response: within four business hours, Monday–Friday. By submitting, you agree to our privacy policy.

Site down right now?