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
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.
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.
1Write down the exact visitor symptom, the time it started, and any change in the last 48 hours (plugin update, PHP bump, DNS edit, deploy).
2Confirm whether the failure is public pages, admin, checkout, forms, or everything.
3Preserve a recoverable copy first: hosting snapshot, off-site backup, or a file-and-database dump if that is all you have.
4Check DNS and SSL before guessing at code: nameservers, A/AAAA/CNAME, certificate expiry, redirect loops, Cloudflare proxy.
5Check the host: disk full, runtime version, PHP error log, process crash, App Service or VM status.
6If 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.
7Apply the smallest safe fix: rollback the last change, disable one conflict, restore one file, correct DNS, or renew SSL.
8Validate as a visitor: homepage, an interior page, login, a form, checkout if you have one, and a phone-sized browser.
9Write 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.
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
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
Snapshot
Take a fresh backup or hosting snapshot where possible before making risky changes, even if the current state is already broken.
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
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
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
Prevent repeat issues
Provide plain-English notes and recommend maintenance, hosting, backups, monitoring, or security hardening only where it directly reduces repeat risk.
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
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.
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.