Ad Account Resilience Runbook: Detection, Failover, and Recovery for Ad Ops Teams

What an ad account resilience runbook is

An ad account resilience runbook is a written, rehearsed incident-response plan that tells your team exactly what to do when an ad account is suspended, compromised, or caught in a platform outage. It exists because the risk is real and the response window is short: Google states that egregious policy violations trigger immediate suspension without prior warning, and when an account is suspended, all ads in it stop running until the account is reinstated.

A complete runbook covers six things: how incidents are detected, how severity is classified, how spend fails over to backup infrastructure, how recovery and reinstatement are executed, who communicates what to whom, and how the team reviews the incident afterward.

Scope every incident before acting. Your first classification step is identifying what is actually restricted:

• Person-level — one user's access or login is affected (for example, a compromised user the platform removes while the account stays live).
• Ad-account-level — the account itself is suspended or restricted and its ads stop serving.
• Page or asset-level — a specific asset is restricted while the wider account remains active.
• Business-level — the entire Business Portfolio, manager account, or business entity is affected, which can cascade across every linked account.

Containment, escalation, and failover differ for each. Google's compromise flow illustrates why scoping matters: when it secures a compromised account, it removes compromised users and unlinks unauthorized manager accounts, but only pauses campaigns the unauthorized user created or modified — untouched campaigns keep serving. Treating a person-level event like a business-level one (or vice versa) leads to either panic or underreaction.

The runbook is also where you record ownership facts before a crisis: which manager account has ownership of each account, who holds Admin access, which payment profiles fund which accounts, and where your campaign migration templates live. Teams that document this in advance avoid the most common failure mode — improvising during an outage.

Incident detection and severity levels

Detection has three layers, and your runbook should assign a named owner to each.

Platform-native signals. Meta's Webhooks for ad accounts can push real-time notifications to your own endpoint — for example, the with_issues_ad_objects field notifies you when a campaign, ad set, or ad under the ad account changes to WITH_ISSUES status, and product_set_issue flags product set problems that affect your ads. Subscribing an app requires a POST to /{ad-account-id}/subscribed_apps, and the app needs edit permission on the ad account plus the ads_management permission. On Google, the Security Agent continuously monitors for activity that deviates from historical behavior — flagging unusual users, anomalous logins, and risky email domains — and surfaces suggestions under Admin → Access and security → Security.

Human checks. Google's own best-practice guidance is to sign in regularly and check for unexpected changes to ads or budgets, review bank or card statements for unauthorized billing activity, and audit who has access. Build these into a weekly checklist with an assigned owner.

Notification channels. A suspended Google Ads account triggers both an in-account notification and an email identifying the violated policies. For repeat violations, Google sends a warning at least 7 days before suspension action; egregious violations arrive with no warning at all — your severity model must handle both cases.

Severity levels. Define them before you need them:

• SEV-1 — Full stop. Account suspended or business-level restriction; all ads in the account stop running. Trigger failover immediately and open the recovery workflow in parallel.
• SEV-2 — Partial impact. Campaign- or ad set-level issues, disapprovals, or a compromised-user event where untouched campaigns keep serving. Contain, remediate, monitor.
• SEV-3 — Early warning. Strike warnings, Security Agent flags, or WITH_ISSUES objects that have not yet stopped delivery. Fix before it escalates.

Each severity should map to a named incident commander, a response-time target, and a pre-approved action list.

Failover and account redundancy

Failover is the part of the runbook that keeps revenue moving while recovery runs in parallel. The design principles:

Redundant accounts, kept warm. AdsInfra's redundancy playbook recommends at least two active accounts per platform for any spend over $50k/month, with backup accounts kept warm at $50–100/day so they carry trust history and can scale quickly. Keep backups live with evergreen or low-priority campaigns rather than leaving them dormant.

Portable campaigns. Structure campaigns for migration: consistent naming conventions, standardized audience definitions, and a creative asset library, with top performers documented in a migration template. Portability is what turns a backup account from a shell into a real failover target.

Billing isolation. Use separate payment methods per account so a billing failure on one does not cascade. Map the dependency risk on Google explicitly: when a payments profile is unlinked from a manager account, billing setups for all accounts using that profile are deactivated, and a new billing setup is required before those accounts can serve again.

Access redundancy. Google warns that an account with only one administrator can lose access to its tags if that person becomes unavailable, and recommends adding at least one additional admin. Apply the same logic to every critical role: billing, advertiser verification, and appeal submission.

Stay inside platform rules. Redundancy is business continuity, not circumvention. Having multiple ad accounts under a single Business Manager is explicitly allowed on Meta, TikTok, and Google — but Google states that accounts related to a suspended account may be suspended, that new accounts a suspended advertiser tries to create may also be suspended, and it recommends reinstating suspended accounts before creating new ones. Your failover plan should move spend to pre-existing, compliant accounts — never spin up new accounts to route around an active enforcement action.

Diversify platforms. The redundancy playbook also suggests keeping no more than 60% of spend on any single platform, so a platform-wide outage becomes a revenue dip rather than a revenue zero.

Recovery and reinstatement workflows

Your runbook should contain a step-by-step workflow per incident type. Two Google workflows are documented in detail and are worth adapting as templates.

Compromised account workflow (Google).

1. Report immediately. Gather change-history timestamps showing unauthorized access, unauthorized manager account IDs linked to the hierarchy, evidence of budget increases or automated rules that deviate from historical management, and your current IP address for verification.
2. Let the platform secure the account. Google temporarily suspends the account, pauses only campaigns created or modified by the unauthorized user, removes compromised users, unlinks unauthorized manager accounts, and sets spending limits to zero on unauthorized new sub-accounts.
3. Re-authenticate. Admins must complete MFA or 2-Step Verification and change the account password before they can review anything — this is a required step.
4. Review the change log. Google emails a detailed activity log to admins who held the role before the confirmed compromise date. If only user and campaign changes occurred, the account is unsuspended immediately after securing; if the account structure was modified, it remains suspended until an authorized admin consents to cleanup. Only one admin can submit the decision — and once submitted, it cannot be changed or reverted.
5. Post-reinstatement hygiene. Scan every device for malware before changing passwords (changing a password while malware is present risks capturing the new credentials), review all users and access levels, audit MCC links and payment profiles, delete or pause unauthorized campaigns, and re-check advertiser verification details.
6. Reimbursement. After recovery, with 2-Step Verification turned on, you can request reimbursement for unauthorized charges; Google states billing investigations can take 10 to 15 business days, and any credits appear as a 'Service Adjustment' on a later invoice.

Suspension appeal workflow (Google). Appeal through the Contact Us link in the in-account notification; the account shows 'Appeal pending' while under review. Submit one appeal at a time — Google may stop processing appeals it considers misuse — and note that all advertisers have at least 6 months from the suspension date to appeal. Google states it reinstates accounts only in compelling circumstances, so be thorough, accurate, and honest. If the suspension traces back to a compromise, remove all violating content and fully secure the account before appealing, and explain those steps in the appeal.

Meta and other platforms. The sources reviewed for this guide do not document Meta's reinstatement timelines or outcomes, so your runbook should treat Meta recovery timing as unknown, track actual durations from your own incidents, and avoid promising stakeholders a restoration date.

Communication and escalation

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

Internal escalation. Name an incident commander per severity level, a backup, and a dedicated channel (a chat room or bridge). The commander owns the timeline log, task assignment, and stakeholder updates. Pre-draft update templates for clients and leadership: what happened, what is affected, what is being done, and the time of the next update.

Admin roster discipline. Google's compromise flow only lets users who held an Admin role before the confirmed compromise date approve change-log decisions, and only one admin can submit. Google also states that, for security and privacy reasons, it cannot disclose exactly which administrators received the change-log email — so your runbook must include a current admin roster and a rule that admins coordinate directly and immediately when an incident opens.

Platform contact. For Google suspensions, the appeal runs through the in-account Contact Us flow. File one appeal at a time: Google warns that filing too many appeals may mean they are not processed, and suspected misuse of the appeals function can suspend processing of certain appeals for 7 days. Log every appeal — date, text, outcome — so the team never duplicates or contradicts filings.

Verify before you trust. Incident windows are prime phishing time. Google states it will never send an unsolicited message asking for your password or other sensitive information, and that it only contacts you from an '@google.com' email domain. Add a verification step to the runbook: before anyone clicks a link or shares credentials during an incident, confirm the sender domain, and for calls, ask the caller to follow up by email.

External parties. If agencies or partners hold admin or partner access, the runbook should say who notifies them, what they are authorized to do during an incident, and how their access is reviewed and offboarded afterward.

Post-incident review

Every incident — including near misses — ends with a structured review within a set window (one week is a common target).

Reconstruct the timeline. Use the platform's change history and, for compromises, the change log Google generates, to establish what happened, when, and by whom. Compare detection time against your severity targets: did webhooks, Security Agent flags, or a human catch it first?

Root cause and contributing factors. Was it a policy issue, a compromised credential, a billing failure, or a platform-side error? Google's recovery guidance points to root causes worth checking every time: malware on devices used to access the account, shared credentials, excessive access levels, and stale user lists.

Hardening actions. Assign owners and deadlines:

• Enforce 2-Step Verification for every user; Google also offers passkeys and multi-party approval, which requires a second account administrator to verify sensitive changes.
• Review Security Agent suggestions at least monthly — it flags dormant users, risky email domains, login anomalies, and admins it suggests downgrading to Standard.
• If you run a manager account, apply security mandates: MCC admins can require 2-Step Verification and restrict allowed email domains across all owned sub-accounts, and sub-accounts can choose stricter settings but not weaker ones.
• Offboard aggressively: remove users who left the company or no longer work on the account, and grant the minimum access each role needs.
• Re-audit related manager accounts and payment profile links.

Update the runbook. Adjust severity thresholds, failover steps, and contact trees based on what you learned, then rehearse: run a quarterly tabletop exercise so the team practices failover and recovery before the next real incident. Track metrics over time — incidents per quarter, mean time to detect, mean time to failover, mean time to reinstatement — so resilience is measured, not assumed.