Emergency WordPress support is the part of site care you only appreciate during a crisis: the site is down, a white screen replaces every page, a 500 error blocks checkout — and every hour of downtime costs orders, leads and Google's trust. This guide explains what counts as a critical incident, what a realistic response time looks like (and what the difference between response and resolution is), how the recovery procedure runs step by step, and what emergency help costs — as a one-off rescue or inside a monthly maintenance plan.
If you are in the middle of an incident right now: take a full backup of files and database before you touch anything, do not reinstall plugins blindly, and collect the PHP error log. Those three steps decide whether the site comes back in an hour or in a day. More on that below.
What counts as a WordPress emergency
Not every problem is an emergency. Emergency support (sometimes called emergency WordPress support or out-of-hours support) applies to incidents where the site is unavailable, losing money or actively harming the brand:
- White screen of death (WSOD) — the page loads empty; usually a PHP fatal error or a memory limit.
- HTTP 500 / 503 errors — plugin conflicts, corrupted files, database connection failures.
- Redirects to third-party sites — a classic symptom of malware; often visible only to Googlebot or mobile visitors.
- Broken checkout in WooCommerce — payments failing or orders not registering; every hour costs real revenue.
- Lost admin access — locked out of wp-admin after a hack or a broken security plugin.
- Google "malicious code" warning — the site is blacklisted in search results.
Everything else — a single broken form, a layout glitch on one subpage, a slow dashboard — is important but not critical, and it goes through the normal ticket queue with the plan's standard response time.
Response time vs resolution time — the difference that matters
A serious SLA promises two different things, and conflating them is the most common misunderstanding in emergency support:
- Response time — how fast a human acknowledges the ticket, starts the diagnosis and communicates the plan. In my plans: critical incidents within 4 h (Care Premium), high priority within 8 h, normal tasks 24–48 h on business days.
- Resolution time — how long until the site works again. This depends on the failure: restoring from a tested backup takes minutes; cleaning a malware infection can take a full working day; a corrupted update on a store may need hours of testing before production goes live again.
Any vendor who guarantees "1 hour to fix everything" is selling fiction. What a vendor can honestly guarantee is a response time written into the contract, a documented recovery procedure and tested backups — which together make resolution fast in practice.
The recovery procedure, step by step
Emergency recovery follows a fixed order — improvisation is what turns an incident into a catastrophe
- Backup first. Take a full copy of files and the database (and pull the latest off-server backup) before changing anything. Without it, every next step is gambling.
- Collect evidence. PHP error log, server log, WordPress debug log, the last changes made (updates, plugin installs, theme edits, hosting changes).
- Contain. If the site is infected: change all passwords, rotate keys, enable maintenance mode or take the site offline if it is leaking data. If a plugin update caused it: deactivate that plugin via WP-CLI (
wp plugin deactivate --allnarrows the culprit fast). - Restore or fix. Choose the fastest safe route: restore from backup and re-apply only verified changes, or fix the specific file/plugin conflict when the backup is stale.
- Verify. Test key pages, forms, checkout (WooCommerce), admin login and the mobile view. Check the Google Search Console status if the site was blacklisted.
- Report and prevent. A written summary: cause, actions taken, what prevents a repeat. If data leaked, support with your GDPR notification duties.
With a monthly plan, steps 1, 2 and 6 are already in place before anything happens — backups run on schedule with periodic restore tests, monitoring alerts about downtime before users notice, and the logs are ordered. That is why incidents on maintained sites are measured in minutes, not days.
How much does emergency WordPress support cost?
Two models, two price ranges
- One-off rescue — you call a developer during an incident, without a subscription. In Poland this typically costs 300–2,500 PLN net depending on the failure: a quick white-screen fix lands near the lower bound; a full malware cleanup with index restoration near the upper one. You also wait for availability — good developers are booked.
- Monthly maintenance plan with emergency cover — plans start at 99 PLN net/month (Care Start) and the higher tiers include an explicit emergency response time: Care Premium adds a 4 h SLA and on-call duty for outages and security incidents, with priority handling in other plans.
The math is uncomfortable but simple: one rescue usually costs more than a year of the entry plan. Emergency support is cheaper when it is a contract clause, not a favour.
How to prepare before the next incident
- Backups that are tested. Off-server copies of files and database, with periodic restore tests — a backup you never restored is a hope, not a backup.
- Monitoring that actually alerts. Uptime, response time and PHP error monitoring, 24/7 — so you learn about the outage from a tool, not from a customer.
- An SLA in the contract. Written response times per severity, a single ticket channel, named responsibilities.
- Access hygiene. An up-to-date list of hosting, domain and panel credentials that the owner controls — not buried in an ex-contractor's mailbox.
- A staging environment. So the next "quick fix" can be tested instead of gambled.
If your site is critical to the business, the right question is not "who fixes it when it breaks" but "what do we have in place so it breaks less — and comes back faster when it does". That is exactly what a WordPress maintenance plan with an emergency SLA is.
Frequently asked questions
What counts as an emergency in WordPress support?
- Critical incidents: site down (white screen, 500/503), redirects to third-party sites, malware infection, broken checkout or payments in WooCommerce, lost admin access and Google's malicious-code warning. These go into the emergency queue with the fastest response time. Cosmetic issues and single-element bugs are handled in the standard queue.
How fast is emergency WordPress support?
Response time — the moment a human acknowledges the incident and starts diagnosis — is up to 4 h for critical incidents in Care Premium, 8 h for high-priority issues, and 24–48 h for normal tasks on business days. Resolution time depends on the failure: a backup restore takes minutes, malware cleanup usually one working day.
Can you fix a site that was hacked?
Yes — it is one of the most common emergency calls. The procedure: backup, identify the entry vector, remove malware, backdoors and redirects, clean files and database, close the vector, restore the site in Google Search Console and monitor the recovery of rankings. If data was breached, I support the GDPR notification assessment.
How much does an emergency WordPress rescue cost?
A one-off rescue costs 300–2,500 PLN net depending on the failure type. A monthly plan from 99 PLN net/month includes monitoring and backups — the factors that prevent most emergencies — and the higher tiers add a contract response time (4 h in Care Premium) with on-call duty.
What should I do in the first 15 minutes of an outage?
Do not reinstall or delete anything yet. Take a full backup (files + database), copy the PHP error log, and note what changed recently — updates, new plugins, hosting changes. Then contact your developer with those three things in hand. If you suspect an infection, change all passwords immediately.
Do you offer emergency support without a monthly plan?
Yes — a one-off rescue is available for outages and malware, with availability depending on current workload. If the site is business-critical, a plan with an SLA is more reliable: the response time is guaranteed by contract, and backups plus monitoring are already in place when the incident starts.
Sources
- WordPress — documentation: debugging
- WordPress — security documentation
- Google Search Console — security issues
- WCAG / EAA — accessibility as a legal requirement
See also: WordPress maintenance & care plans, WordPress technical support — scope and pricing and WordPress malware removal.
📖 Zobacz również: technical care & SLA.