Ad Account Resilience Runbook: Incident Detection, Failover, and Recovery Workflows

What an ad account resilience runbook is

An ad account resilience runbook is the documented, rehearsed procedure your team follows when advertising infrastructure fails: an account is disabled or restricted, a Business Portfolio loses access, billing stops, or the platform itself degrades. It converts a high-stress scramble into a sequence of assigned, pre-approved steps.

It helps to borrow a distinction from infrastructure operations guidance: runbooks provide step-by-step procedures for well-understood, routine operations, while playbooks guide your response to incidents with less predictable outcomes. In ad operations, rotating a payment method or pausing objects via an automated rule is a runbook item; responding to an unexplained account restriction is a playbook item. Your resilience document should contain both.

A complete runbook covers four scopes of failure, because platforms enforce at different levels:

- **Person-level:** an individual user loses advertising access, is flagged, or has compromised credentials. - **Ad-account-level:** the account is disabled, restricted, or held in review. - **Page-level:** a Page is restricted or unpublished, which can block delivery and — on Meta — block new ad account creation for the business. - **Business-Portfolio-level:** the Business Manager itself is restricted, cascading to every asset it owns.

Each scope has different detection signals, owners, and recovery paths. Treat them as separate incident types in your runbook, not one generic 'account problem.'

Incident detection and severity levels

Detection has three layers: platform-pushed signals, polled signals, and human signals (a buyer noticing spend has stopped).

**Platform-pushed signals.** Meta's Graph API webhooks for ad accounts deliver real-time notifications for certain ads changes. Subscribing an app to the `with_issues_ad_objects` field notifies you when a campaign, ad set, or ad changes to the `WITH_ISSUES` status, and the payload includes the object ID, level, and an error code, summary, and message. Webhooks also cover in-process objects, product set issues, and creative fatigue. Meta's automated rules are a no-code complement: rules can send notifications or pause objects when evaluation conditions are met.

**Polled signals.** On a schedule, read the ad account's `account_status` field. Meta documents the states: 1 = ACTIVE, 2 = DISABLED, 3 = UNSETTLED, 7 = PENDING_RISK_REVIEW, 8 = PENDING_SETTLEMENT, 9 = IN_GRACE_PERIOD, 100 = PENDING_CLOSURE, 101 = CLOSED. When an account moves to DISABLED, read `disable_reason` — Meta enumerates reasons ranging from ADS_INTEGRITY_POLICY and RISK_PAYMENT to COMPROMISED_AD_ACCOUNT, and the reason changes your first response (policy review versus security lockdown). Pull the ad account activities edge for an audit trail of status changes, billing events, and user additions; note that this API returns one week's data by default, so export it before the window closes.

**Severity levels.** A practical mapping:

- **SEV1** — Business Portfolio restricted, or all accounts disabled simultaneously. Revenue stopped. Executive visibility required. - **SEV2** — a primary ad account disabled or restricted. Spend halted on that account; failover executes. - **SEV3** — ad-level disapprovals, product set issues, or payment declines. Partial delivery impact. - **SEV4** — warnings, recommendations, single-ad rejections. Monitor only.

Map each severity to a named owner, a response-time target, and a pre-authorized action list. AWS's advertising-operations guidance recommends defined severity levels with clear escalation paths for high-impact incidents — the goal is that minor issues do not clog the system while major ones get immediate leadership attention.

Failover and account redundancy

Failover means spend keeps flowing through healthy infrastructure while the affected account is worked on. Redundancy is the precondition: you cannot fail over to assets you do not have.

**Core redundancy patterns:**

- Run at least two active ad accounts per platform for any meaningful spend, and keep backups *warm* with low daily spend so they carry billing and delivery history. A cold account is slow and risky to scale under pressure. - Use separate payment methods per account. AdsInfra's redundancy guidance warns against shared cards, because a billing issue on one account should not cascade across your portfolio. - Hold durable assets — the pixel/dataset, the verified domain, core custom audiences — in a separate 'asset holding' Business Portfolio and share them to operating accounts as a partner. If an operating account is disabled, the data layer survives and failover campaigns keep their signals. - Document top campaigns in a migration template (naming conventions, audience definitions, creative library, budgets) so replication to a backup account takes hours, not days.

**Ownership, access, and billing design matter as much as account count:**

- Meta's business APIs distinguish whether your business acts as `OWNER` or `AGENCY` of an ad account. Decide deliberately between business-owned accounts with agency partner access (the client retains ownership, billing control, and can remove agency access at offboarding) and agency-owned infrastructure that the brand rents into. Each model changes who controls billing, who holds admin tasks, and what offboarding looks like. - Note the structural constraints: claiming an account into a Business Manager is one-time, and you cannot remove accounts you own once the claim is CONFIRMED — only pending claims or AGENCY-access accounts can be removed. Plan the target structure before claiming anything. - API-based ad account creation is limited to 5 accounts; more requires manual creation. Meta also blocks new account creation while existing accounts in the Business Manager are in bad standing or in review — so keeping the portfolio healthy is part of redundancy, not an alternative to it. - Stay inside the rules: multiple accounts under one Business Manager are a normal, documented structure. Creating accounts to circumvent enforcement on a restricted account is not. Failover should route spend to pre-existing, compliant accounts — never to evade a review.

This mirrors how platforms design for failure at their own scale: Meta's Maelstrom system drains traffic from failing datacenters to healthy ones, using health monitoring and feedback control so constraints hold during the move, and Meta reports it has been used to mitigate and recover from 100+ datacenter outages. Your failover plan is the same idea at media-buying scale: shift spend to a warm, healthy account while the primary is worked on.

Recovery and reinstatement workflows

When a SEV1 or SEV2 incident is declared, execute in this order:

1. **Confirm scope.** Distinguish a platform-wide outage from an account-specific problem before changing anything: check status surfaces, community reports, and whether comparable advertisers are still delivering. The correct response to a delivery outage is different from the response to a restriction — pausing healthy campaigns during a mere attribution or reporting outage is a classic self-inflicted error. 2. **Secure the perimeter.** If the disable reason suggests compromise (Meta documents COMPROMISED_AD_ACCOUNT as a disable reason), revoke sessions, rotate access tokens, enforce two-factor authentication, and remove unknown users and apps *before* appealing. 3. **Stabilize spend.** Execute the failover plan: raise budgets on the warm backup within pre-approved limits and pause or cap the affected account. Avoid mass edits elsewhere during instability. 4. **Appeal through official channels.** Submit the review request with a concise, factual summary and supporting evidence. Be honest internally about uncertainty: Meta does not publish official reinstatement timelines or guarantee outcomes. Practitioner guidance from AdsInfra indicates even successful appeals typically take 3–14 days, and some restrictions are permanent. Plan cash flow assuming recovery may not arrive. 5. **Reconcile after restoration.** Compare billed amounts against delivery, and expect attribution back-fill: after Meta outages, click-through attribution typically back-fills within 24–48 hours and modeled or view-through conversions can take longer. Do not draw performance conclusions, or make major budget and creative decisions, until roughly 72 hours of clean data has accumulated. 6. **Failback deliberately.** Practitioner outage guidance warns that the 24 hours after restoration can be as dangerous as the outage itself. Return budgets to the recovered account gradually — in a controlled, low-activity window with health checks — rather than flipping everything back at once, and avoid major edits until delivery and CPA have re-stabilized.

Communication and escalation

Incidents fail on communication more often than on technique. Define these elements in advance:

- **Roles.** An incident commander (owns the timeline and decisions), an ad ops lead (executes containment), a platform liaison (opens support tickets and tracks case IDs), an analytics owner (confirms impact and scope), and a communications owner. Assign a backup for every role, including off-hours coverage. - **Cadence.** A fast first internal update — structured runbooks commonly target under 30 minutes — then a fixed schedule (for example, every 30–60 minutes for SEV1/SEV2) until resolution. - **Two tracks.** Internal updates carry hypotheses, actions, and owners. Client and executive updates state what happened, what you are doing, current spend exposure, and the next update time — without speculation. Pre-approve message templates with legal and leadership so approval never delays the first note. - **Escalation triggers.** Define them explicitly: a missed milestone (no platform response within your threshold), scope expansion, or an incident upgrading from account-level to Business-Portfolio-level. Name who can declare SEV1 and who can authorize budget reallocation.

Two hard rules from outage-response practice: send one proactive, factual message early rather than a stream of speculation; and do not commit to make-goods or compensation before post-incident reconciliation is complete — mid-incident numbers, especially attribution gaps, frequently correct themselves as data back-fills.

Post-incident review

Within 72 hours of stabilization, run a blameless postmortem. Required content:

- **Timeline with timestamps:** first signal, declaration, containment, platform responses, restoration, failback. - **Root cause and contributing factors**, classified at the correct level — person, ad account, Page, Business Portfolio, or platform-wide. - **Impact quantification:** spend interrupted, revenue delta, and effects on learning phases and data freshness. - **Detection path:** what caught the issue first, and whether a webhook, status poll, or alert rule could have caught it earlier. - **Action items with owners**, with runbook updates applied immediately rather than parked in a slide deck.

Then rehearse, because an untested runbook is a hypothesis. Meta's own infrastructure team verifies its Maelstrom disaster procedures by running large-scale tests that drain production traffic from entire datacenters and restore it; AWS's advertising-operations guidance likewise says to review and update runbooks after each incident or significant operational event and to conduct regular simulation exercises to validate playbook effectiveness. The ad-ops equivalent is a quarterly tabletop exercise plus at least one live failover drill: simulate a disabled primary account, execute the migration template onto the warm backup, and time every step.

Track two metrics across real incidents and drills: mean time to detect (MTTD) and mean time to recover (MTTR). Those two numbers tell you whether the runbook is working — and where to harden next.