Who Actually Owns WordPress Incident Response During a Redesign Launch? Turning Hosting, IT, and Agency Chaos Into a Runbook

Marketing signs off the new WordPress redesign on Friday. Traffic spikes, ads are live, email campaigns are queued—and by Saturday morning, checkout errors start appearing. Hosting says the server is fine, IT is offline, the agency is replying slowly, and you’re the one being pinged by sales.

For supporting context before making that decision, Website Redesign articles explains the adjacent issue in more detail.

During a WordPress redesign launch, one business owner must own incident response, with a written 24/7 runbook that defines roles, escalation paths, SLAs, and who can trigger rollbacks.

This isn’t just about uptime. It’s about who decides what happens in the first 15 minutes of trouble, and who is allowed to take risk on behalf of the business.

We’ve already treated hosting ownership as its own governance decision; if you haven’t aligned on that yet, use the hosting-ownership article as a prerequisite to this one: Who Actually Owns WordPress Hosting Decisions During a Redesign? Untangling Agency, IT, and Marketing Roles.

This piece assumes hosting ownership is settled and escalates the question: when the redesigned site misbehaves, who runs the incident and according to what playbook?

---

1. The real incident risk during a redesign isn’t uptime—it’s ownership

During redesign launches, the pattern repeats:

• The site goes live.
• Something subtle but serious breaks—checkout, lead forms, search, login.
• Everyone assumes someone else is in charge.

In support work, we often see the same scene play out in group chat:

“Is this a hosting issue or a code issue?"
"Can someone check DNS?"
"Who can roll back?"
"Does anyone have production access?”

No one technically owns the incident. Marketing is stuck convening the host, IT, and the agency—none of whom believe they’re formally on point.

The visible symptoms are familiar:

• Slow triage. Ten precious minutes disappear just figuring out who should even look.
• Finger-pointing. Hosting blames code, the agency blames plugins, IT blames WordPress.
• Silent customers. Cart errors, 500s, or broken forms run quietly in the background.

The real risk isn’t that something breaks; it’s that no one is empowered to act decisively when it does.

That’s why this article is a recovery asset: its job is to convert “call everyone and hope” into a simple, named-owner runbook for launch week and the first 90 days.

---

2. Clarify the decision: who is the single owner of WordPress incident response for launch + 90 days?

You’re not deciding who fixes every bug. You’re deciding who owns the incident.

Let’s separate two concepts that get blurred:

• Incident fixing: hands-on technical work—editing code, reverting deployments, clearing caches, adjusting DNS, disabling plugins.
• Incident owning: coordinating people, setting priorities, deciding when to roll back, communicating with stakeholders, and closing the loop.

The owner doesn’t have to be the most technical person. They must:

• Be reachable 24/7 (or have an on-call rotation).
• Have authority to interrupt campaigns, pause ads, or trigger a rollback.
• Have enough technical context to convene the right people fast.
• Be accountable for the post-incident review.

During launch + 90 days, you cannot leave this to a committee. Committees:

• Debate while customers see errors.
• Spread responsibility so thin that nothing gets decided.
• Encourage risk-averse behavior like “let’s wait and see if it’s still broken in the morning.”

So the decision you’re really making is:

Which named role is the Launch + 90 Days WordPress Incident Owner, and what authority do they have?

In most organizations, that’s one of:

• A marketing operations leader (if the site is revenue-critical and marketing is effectively product owner for the website).
• A digital product manager / web lead (if that role already bridges business and technology).
• A senior IT / digital infrastructure lead (if IT already runs customer-facing web operations, not just internal systems).

Our point of view: marketing leadership often needs to sponsor this decision even if they are not the incident commander, because they feel the business impact fastest and can ensure the owner’s authority is real.

---

3. Map the four players: hosting, IT, marketing, and agency—and what they actually control

During a WordPress incident, four groups show up. Confusion comes from assuming they can all do the same things.

Hosting (the WordPress platform)

Controls:

• Server resources and scaling.
• Database performance.
• Backups and restores.
• SSL, some security layers, sometimes WAF/CDN.

Typically cannot decide alone:

• Whether a newly deployed theme or plugin is safe.
• Which features to disable temporarily.
• Whether a partial rollback is acceptable from a marketing or compliance perspective.

When hosting is fully managed for WordPress, they’re best positioned to be the technical first responder—but they still need a business-side owner to authorize big moves.

Internal IT

Controls:

• Network, SSO, VPN, possibly DNS and email.
• Security policies, change management, and sometimes vendor contracts.
• Access to wider monitoring and incident tooling.

Often the wrong primary owner for WordPress-specific failures. Why:

• Their focus is usually internal systems and security, not conversion paths.
• They may not own the relationship with the agency or content team.
• They may be constrained by strict change windows.

They’re vital stakeholders, but during a redesign launch, “IT owns everything web” often slows response, especially outside business hours.

Marketing / digital / business owner

Controls:

• Release timing, campaigns, and traffic drivers.
• Definitions of “this is broken enough to hurt us.”
• Acceptance criteria for temporary fixes (maintenance page vs. degraded experience).

Typically cannot do alone:

• Touch production infrastructure safely.
• Evaluate subtle technical causes without help.

But in every serious incident, marketing or business leadership needs to answer: “Are we okay with this risk, or do we pull back?” If they’re not explicitly in the loop, technical teams guess at business tolerance.

Agency / dev partner

Controls:

• Theme, plugin, and custom-code changes.
• Release packaging and deployment scripts (if they manage CI/CD).
• Fix-forward plans and refactors after the incident.

Should not be your de facto 24/7 incident response team. Common traps:

• Assuming the agency watches your site all weekend.
• Expecting instant response from a team not on a formal SLA.
• Giving the agency production keys without guardrails.

Relying on your redesign agency as your permanent incident owner is a risky, temporary patch at best. They’re a critical participant, but the owner must sit inside your business or with a managed hosting partner under explicit agreement.

---

4. The Launch + 90 Days Incident Runbook: a practical, one-page structure

Once you’ve named the owner, they need a one-page runbook—not a 40-page policy no one reads.

Here’s a structure we see work well for the launch + 90 days window.

1) Triggers

Define exactly what counts as an incident during this period. Examples:

• Any 500 error on critical flows (checkout, lead form, login).
• Conversion or lead volume dropping suddenly against normal patterns.
• Page load suddenly degrading on key templates.
• Security alerts on the new theme, plugins, or integrations.

Make it explicit: Who is allowed to declare an incident? (Answer: anyone on the web, marketing, IT, or support teams, but the owner decides severity.)

2) Severity levels

Keep it simple:

• SEV1 – Business-stopping. Customers cannot buy, submit leads, or log in.
• SEV2 – High impact. Major friction in key flows; revenue or lead risk is high but not total.
• SEV3 – Degraded experience. Errors or layout issues that don’t immediately hit revenue but damage trust.

The runbook should say, in one line each, what SEV1, SEV2, and SEV3 demand in terms of hours to first response and who must join the call.

3) First responder and communication channel

Spell out the escalation path as a realistic chat pattern, for example:

• Incident declared in the web-ops channel by anyone.
• Incident Owner is tagged: “@Owner checkout errors on /cart, seeing multiple support tickets.”
• Owner immediately @-mentions hosting support and the agency lead, and loops in IT if DNS, SSO, or security might be involved.

The runbook should include one primary channel and a fallback if chat is down. No fishing across five different tools.

4) Escalation path

Document the order of calls, not just the list of teams:

1. Hosting support (to rule out infrastructure, restore from backup if needed, and surface logs).
2. Agency / dev partner (to review recent commits, feature toggles, or deployments).
3. IT (if DNS, SSO, firewall, or internal integrations could be involved).
4. Business approver (usually the marketing or digital lead) for rollbacks, maintenance pages, or pausing campaigns.

Write actual names and contact methods. “Agency” is not a contact.

5) Rollback criteria

This is where most organizations freeze. Define before launch:

• For SEV1 incidents, do we roll back after 15 minutes, 30 minutes, or 60 minutes if not resolved?
• Which decision-maker can say, “We’re reverting to the previous version and pausing the rollout, even if the new design isn’t fully live”?
• Do we have a temporary safe mode (limited plugins, stripped features) that hosting can enable without another approval loop?

The point: the rollback decision should be execution, not negotiation.

6) Communication list

List who gets what updates:

• Executives: summary every 30–60 minutes for SEV1, with clear business impact.
• Sales/support: status they can share with customers.
• Broader org: only if the incident is long-running or reputation-sensitive.

And decide who writes these updates. It should not be the most technical person in the room.

7) Post-incident review

Within a few days, the Incident Owner runs a short review:

• What happened?
• What was the business impact?
• What slowed us down?
• What do we change in the runbook, platform, or process before the next incident?

Capture fixes that move you up the Maintenance Maturity ladder (more on that shortly).

---

5. Hidden failure modes to design around before launch week

Ownership issues during launch aren’t just about “who’s on call.” They’re about gaps almost no one writes down.

Here are common failure modes we’ve noticed in redesign planning and support work.

Off-hours blind spots

Launch happens Friday; problems show up Saturday or Sunday.

• The agency works weekdays only.
• IT is on a strict on-call rotation focused on internal systems, not the website.
• The only person watching dashboards is a marketer checking campaign metrics.

Design around this by naming who is reachable off-hours and what support level you actually have from each party.

DNS and SSL changes

Subtle DNS or SSL mis-steps can take parts of the site down or make logins flaky. The “it’s just DNS” assumption hides that:

• Marketing rarely owns DNS.
• Agencies often don’t have DNS access.
• Hosting may or may not manage DNS for the domain.

Make DNS changes a named step in the runbook with a specific IT or hosting contact.

Plugin and theme conflicts

In the first weeks after launch, plugins and themes are the landmines: security patches, compatibility issues, or conflicts with custom code.

If you want to think more broadly about who governs these decisions beyond the incident lens, the plugin and theme governance article is a useful expansion, because it shows how ownership of components affects failure risk: Who Owns Plugin and Theme Decisions During a WordPress Redesign? Governance for Security, Performance, and Marketing Agility.

For incident response, the key is knowing who can safely disable a plugin and under what conditions.

Agency access and production safety

A frequent hidden risk: the agency has broad production access, but there are no clear guardrails. In one common pattern, launch-day issues were resolved only after hours of confusion because:

• The agency assumed hosting would roll back.
• Hosting assumed the agency owned code and deployments.
• Marketing assumed IT controlled production access.

As a contrast, separate guidance on sandbox access shows how to keep agencies productive without handing them unchecked control of production; that idea is useful context even though it tackles a different part of governance: How to Give Your Redesign Agency a Safe WordPress Hosting Sandbox (Without Handing Over the Keys to Production).

In your incident runbook, clarify:

• Who has production credentials.
• Who can approve changes to those credentials during an incident.
• Whether the agency is allowed to hotfix directly on production.

Rollback confusion

The most expensive failure mode we see is not “we couldn’t fix it.” It’s “no one knew if we were allowed to roll back.”

A typical scenario during launch week:

• The new checkout is partially live. Some customers can’t complete purchases.
• Marketing fears losing the redesigned funnel they just launched.
• Product wants more data before pulling back.
• Hosting is ready to restore a backup but won’t move without clear approval.

You lose hours because rollback wasn’t pre-decided. That’s why the runbook must name who can say, “We’re reverting now; subject closed.”

---

6. Applying Maintenance Maturity to incident response during a redesign

Think of incident response during a redesign as a quick test of your Maintenance Maturity—how you move from reactive fixes to proactive ownership and continuous improvement.

For launch + 90 days, you don’t have time for a full transformation, but you can move up the ladder just by tightening ownership.

Here’s a pragmatic view of how Maintenance Maturity shows up in incidents:

1. Ad hoc (“just call whoever”).

   • Incidents are noticed by chance.
   • Group chats spin up with no clear lead.
   • Rollback is a last-resort panic move.

2. Named owner, no runbook.

   • One person is informally seen as “the web person.”
   • Response depends on their memory and availability.
   • Incidents resolve, but nothing is documented.

3. Launch + 90 Days runbook in place.

   • Owner and severity levels are defined.
   • Hosting, IT, marketing, and agency know their roles in an incident.
   • Rollback criteria exist, even if imperfect.

4. Integrated, hosted-backed operations.

   • Monitoring, alerting, backups, and runbooks are aligned with your hosting partner’s capabilities.
   • Incidents automatically trigger the right response team.
   • Post-incident reviews feed into roadmap and process changes.

5. Continuous improvement culture.

   • Incidents steadily get shorter and less frequent.
   • Launches feel routine, not heroic.
   • The runbook becomes part of your broader digital governance.

Launch + 90 days is a distinct governance window because:

• Risk is higher: new code, new flows, and new integrations are still settling.
• Traffic is often higher: campaigns, PR, and sales pushes highlight the redesign.
• Teams are still learning how the new system behaves.

You don’t need level 5 maturity by launch. You do need to jump from “ad hoc” to at least “runbook in place.” Otherwise, every issue in that period turns into a full-company fire drill.

If you want to see how this fits into a larger set of governance decisions you lock in before major design changes, the governance guide on hosting during a redesign serves as an escalation of this maturity model: WordPress Hosting During a Redesign: Governance Decisions You Must Lock In Before You Touch the Theme.

---

7. Turn your decision into operations: how fully managed hosting underpins the runbook

A runbook without an operational backbone is just a document on a shared drive.

This is where fully managed WordPress hosting earns its keep during a redesign launch.

When the host is a true operational partner, not just a server vendor, they can:

• Provide 24/7 monitoring and alerts aligned to your severity levels.
• Offer fast restores and safe rollbacks because backups and environments are designed for it.
• Give you clear support SLAs that match your Launch + 90 Days risk.
• Participate in your post-incident reviews with real insight into patterns and platform limits.

In support work, we’ve noticed that incidents resolve dramatically faster when the host is explicitly named in the runbook as first technical responder, and the internal Incident Owner treats them as part of the team, not an external ticket queue.

If you want your runbook to map onto a platform that actually supports this level of ownership, it’s worth looking at how our WordPress Hosting (Fully Managed) service is structured to operationalize monitoring, SLAs, and incident escalation instead of treating them as afterthoughts.

---

8. Make the call now: choose an owner, codify the runbook, and brief the team

Here’s what should happen before your redesign launch date is locked—or as soon after as you can manage if you’re already in motion:

1. Name the Incident Owner for launch + 90 days. Put their name in writing, and make sure executives endorse their authority to trigger rollbacks and pause campaigns.
2. Draft the one-page runbook. Include triggers, severity levels, first responder, escalation path, rollback criteria, and communication list.
3. Brief every participant. Hosting, IT, marketing, and the agency should see the runbook and know their role in it.
4. Run a 30-minute tabletop. Walk through a realistic scenario: “Checkout errors start Saturday morning; show me the first 30 minutes.” Adjust the runbook based on where people hesitate.
5. Tie it into Maintenance Maturity. After the first couple of incidents, use post-incident reviews to upgrade weak spots instead of just saying “glad that’s over.”

If you don’t do this, the consequence is predictable: no named incident owner → slow triage and finger-pointing → prolonged downtime or broken flows → revenue and trust loss during your most visible phase → frustrated executives and rushed, risky fixes that increase long-term maintenance debt.

If you read this and realize your organization doesn’t have the operational backbone to support the runbook you want—especially around monitoring, out-of-hours coverage, and safe rollbacks—then you’re looking at a hosting and governance gap, not just a documentation task.

That’s exactly the gap our managed hosting work is designed to close: an engagement around WordPress Hosting (Fully Managed) would examine how your platform, monitoring, backups, and support structure align to the incident owner and runbook you’ve just defined, and then produce a concrete plan to make your launch + 90 days calmer instead of chaotic.

To apply this decision to your own website, discuss the next step with our team.

For broader redesign governance and planning context—so incident response isn’t treated as an isolated checklist—you can also explore our archive of Website Redesign articles, which expands this ownership model into hosting, plugins, environments, and sequencing of changes.