Skip to content

Emergency response

Every agency says they will be there. Almost none write it down.

This page is what that promise actually means when we put it on paper: what counts as an emergency, who does what, how fast, and what you can do yourself in the first five minutes while you wait.

38 min Report to diagnosis On the incident below
15:01 Stable, same day No data loss
5 Parts to the document Priorities, protocol, times, escalation, runbook
2 Actions for your team Before we even reply

01 · What an attack looks like

Not what people expect.

A real sequence, from a recruitment client’s WordPress site.

09:57

The client reports the website is down

It was not down. An IP block applied during overnight mitigation had caught their own office IP address, so the site was unreachable for them and fine for everyone else.

10:35

Correct diagnosis, IP unblocked

The site is slow but serving. So far this looks like a performance problem.

11:12

The real damage surfaces

The connection to the applicant tracking system has dropped and stopped syncing. The public site still loads. Job listings still display. Application forms still render. But no new roles can be published and no applications can be processed. In the client own words, the site had stopped business.

15:01

Site stable, same business day

The cause was bot-driven DDoS and brute force traffic consuming the server resource allocation.

Next day

Confirmed back to normal

Site speed normal and the ATS sync working. No data loss. Every application submitted during the incident had been captured locally and synced once load dropped.

Why that happened

Because autoscaling had been deliberately turned off, to avoid an uncapped bill, the server hit a hard ceiling and started shedding work. It kept the public pages alive and dropped the third-party API calls first. Keeping that load off the server in the first place is bot and crawler work, not incident work.

Under load, WordPress degrades in an order that protects the thing you can see and sacrifices the thing your business runs on. By the time anyone notices, the integration has been failing for hours. The full case study follows that morning hour by hour.

02 · The deliverable

Why a runbook beats a retainer promise.

When a site goes down, the person who notices is usually not technical. It is the marketing manager, or whoever happened to check. The gap between something is wrong and the right person is working on it is where the damage accumulates.

01

Priority definitions

Vague severity levels are useless under pressure. Critical means business-critical failure that stops operations. On a recruitment site that is: site fully down, site-wide fatal errors, the ATS connection failing, a confirmed security breach, SSL failure blocking access, or the database unavailable.

High means a specific feature is broken while the site is operational and core operations are not blocked. A contact form not delivering. A page erroring. Significant performance degradation.

RuleThe ATS connection is on the critical list even though the site is still loading, because in that business it stops revenue.

02

A communication protocol that works at 11pm

One channel, monitored. Email, with a subject line convention that makes a critical incident visibly critical in an inbox rather than sitting between two newsletters.

RulePhone calls, texts and messaging apps are explicitly not support channels, because a channel that is only sometimes monitored creates the belief that a message was received.

03

Response times, stated

Separate times for business hours, out of hours on weekdays, and weekends and public holidays. Stated as time to acknowledgement and commencement of work, not time to resolution, because nobody can honestly promise a fix time for a problem they have not seen yet.

RuleFor genuine critical incidents, work can begin immediately with billing approved retrospectively up to a capped amount, so no site sits broken waiting for a purchase order.

04

Escalation on both sides

Your contacts, in order, up to and including who we call if nobody answers. Our cover arrangements, including holidays. And an honest fallback for the scenario where nobody on our side is reachable at all, which for us means a route to another qualified developer within minutes.

05

The first five minutes, for your team

Enable Under Attack mode. One toggle. It challenges every visitor for five seconds and stops most automated traffic immediately. Verify it worked by loading the site in a private browser window and confirming the challenge screen appears.

Block the source. Identify it in Cloudflare security analytics, then block either a specific IP through the IP Access Rules, or an entire country through a custom firewall rule.

RuleWe ask clients to run through the first step once while nothing is wrong, so the first time they use it is not during an incident.

03 · Limits

What is honestly outside our control.

Three things, and we put them in the SLA rather than discovering them together during an outage.

Third-party platforms

We can chase, not fix

If the failure originates with an ATS, a CRM, a payment provider or a plugin vendor API, our response time covers investigation and escalation. It cannot cover their fix time.

Server uptime

Governed by your host

That is your host own SLA, not ours. We will tell you when the answer is with them.

Protocol

The clock starts on the defined channel

Response times apply to requests that come in through the agreed channel. A message sent somewhere else does not start the clock.

04 · What you get

Seven things, on paper, before you need them.

  • Written priority definitions, specific to your site and the systems it depends on
  • A communication protocol with a subject line convention
  • Response time commitments by priority and by time of day
  • Out of hours and holiday cover arrangements, including what happens when your usual contact is away
  • A two-tier escalation path on each side
  • A step-by-step attack runbook your non-technical team can follow
  • Documentation of every security rule currently applied to your site

The document is drafted by us and edited by you. On the recruitment engagement, the client made their own edits directly and the final version was jointly owned, which is the right outcome: an SLA you did not help write is one you will not follow. The plan sits alongside the configuration work in our WordPress security service.

An incident plan is one piece of our wider WordPress security work, and business-hours cover, monitoring and updates are handled through maintenance.

Common questions

Do you offer 24/7 support?+

We offer defined out-of-hours response for critical incidents, with a stated acknowledgement time, which is a different thing from a permanently staffed desk and we say so plainly. A small studio claiming round-the-clock coverage is either lying or subcontracting. What we do is commit to specific times, at specific rates, with a real fallback route when we are genuinely unreachable.

What happens if you are on holiday?+

Cover is arranged so that the whole team is never away at once, and that arrangement is written into the SLA rather than assumed. The document also names a last-resort route to another qualified developer, for the scenario where that arrangement fails.

Is emergency response included in a maintenance retainer?+

Business-hours support is. Out-of-hours emergency response is charged separately at a defined rate, because pricing it into every retainer means every client pays for a service most of them never use. The rate and the approval process are in the SLA, so there is no negotiation happening while your site is down.

We already have a maintenance agreement with someone. Can you just do the plan?+

Yes. The incident plan and the runbook can be produced as a standalone piece of work. We will need read access to the site and to whatever CDN or firewall sits in front of it.

What if we get attacked again after the work is done?+

That is the assumption the whole document is built on. There is no configuration that guarantees an attack will not happen again, and anyone telling you otherwise is selling something. What changes is the response: measured instead of improvised, with your team able to act in the first five minutes rather than waiting.

Can you help right now, mid-incident?+

Get in touch and say it is urgent in the subject line. We will tell you honestly whether we can act immediately or not, rather than taking the job and leaving you waiting.

Keep reading

The worst time to write an incident plan is during an incident.

If your site matters to your revenue and you do not currently have one, that is the whole case for this piece of work.

Book a scoping call
Ali Demirci
Ali Demirci
Founder
What counts as critical on your site
Written against your business, not a template.
Who acts, and how fast
Stated as acknowledgement times, not fix times.
What your team can do alone
Two actions, rehearsed once.