Platform Outage vs Account-Specific Problem: A Cross-Platform Incident Classifier

Direct answer

Do not diagnose from zero spend, green status, or one label. Freeze product, IDs, UTC time, region, last-good export, and error. Compare path-distinct evidence: status/history, another authorized viewer, UI/API, owned delivery/backend telemetry, payment/verification notices, and identity/network/integration logs. Classify provider-wide, product/region, account, reporting-only, local, or shared dependency; cause remains a hypothesis. Contain one reversible risk, use the official route, and accept recovery only after the gate.

Who this is for

Fit: executives, incident leads, finance owners, security leads, agencies, and client administrators running high-spend Meta, Google Ads, or TikTok programs that must distinguish a provider event from an account, data, access, or dependency failure.

Not a fit: not a generic status-page explainer, platform-specific appeal page, legal/insurance advice, forensic conclusion, or reinstatement service. It does not infer an outage from zero spend, promise review timing, or recommend account replacement, identity rotation, credential sharing, or indiscriminate chargebacks. Linked survival resources apply after classification; they are not evidence for it.

Decision model

Classify by failure path, not label

A class is independent only when its confirming signals do not depend on the same failing path. A status page and an API response from one provider may be two views of one path. A delivery export and a bank record are path-distinct, but answer different questions. Record the path for every signal.

Synthesis/inference: this operating classifier adapts platform-specific evidence, provider/user observability research, and common-mode dependency analysis; it is not a probability model or outage detector. The reporting-only branch is also an operating inference: [PR-P18] reports reporting/data-isolation symptoms, not proof that delivery or settlement continued; confirm continuation from served and backend records. [RS-S07][RS-S17][RS-S18][RS-S19][RS-S23][PR-P01][PR-P09]

Bound historical incidents

• Industry reporting on 2024-03-05 described Meta login disruption alongside Ads Manager creation, delivery, and reporting symptoms. It supports a broad/product hypothesis, not every advertiser's delivery or loss. [PR-P17]
• Reporting on 2024-08 described Google report/product unavailability and a small-fraction cross-account product-serving event followed by report quarantine. It is not a prevalence claim. [PR-P18]
• Search Engine Land reported some Google campaigns stopped serving on 2025-03-01/03 and quoted investigation/resolution notices, while cause and broad scope remained unclear. Later status silence is not concealment proof. [PR-P21][PR-P09]
• On 2025-01-19, a U.S. TikTok legal trigger coincided with Cloudflare-observed DNS traffic falling by up to approximately 85% and later restoration. DNS is not TikTok Ads delivery telemetry. [PR-P22][PR-P25]

Diagnostic or control sequence

Run in order. Every step names input, owner, action, and stop/branch logic. Combine roles only when authority remains explicit. [RS-S03][RS-S09][DRS-A01]

1. Capture and freeze the symptom.

   • Input: exact label/error, platform/product, account/portfolio/manager/campaign IDs, region/entity, UTC first-seen time, last-known-good export, recent changes, status URL, case ID, and business symptom.
   • Owner: incident lead; recorder owns chronology.
   • Action: state what is broken in observable terms; preserve raw exports/notices and record unknowns. Separate zero reports, zero impressions, zero attributed conversions, and delivery failure for a frozen scope.
   • Stop/branch: stop nonessential mutation if pre-change state is not captured, evidence may be overwritten, or no approver exists. If only a report is blank, branch to reporting-only; if no authorized delivery record exists, keep delivery unknown. [DRS-A01][RS-S03][RS-S07][PR-P18]

2. Check scope and path independence.

   • Input: provider status/history, product-specific status object, official notice, adjacent product/region comparison, second authorized viewer, UI/API comparison, known-clean device/browser, and permitted alternate network path.
   • Owner: platform liaison; security/asset owner owns access tests.
   • Action: capture status URL, product, timestamp, wording, and scope. Repeat the minimum read-only observation through a second organization or identity; compare errors, request IDs, permissions, and timestamps.
   • Stop/branch: provider-wide requires corroboration across unrelated accounts/regions and a matching path. One surface/region means product/region. One identity, endpoint, token, or network means local. If no status entry exists, continue; absence is not proof of no incident. [PR-P01][PR-P09][PR-P21][RS-S19][PR-P12]

3. Check account state and reporting integrity.

   • Input: in-account restriction/verification/payment notice, policy/detail ID, invoice/transaction, entity/region, parent-child map, served-delivery export, billing ledger, report query/freshness, analytics, and backend settlement.
   • Owner: asset owner approves account actions; finance owns billing; measurement owner owns reporting; entity owner owns document/jurisdiction questions.
   • Action: classify reachable-but-read-only, payment-risk, verification-gated, policy-restricted, or linked-container state. Quarantine report-driven budget/performance conclusions while comparing billed, served, attributed, analytics, and settled ledgers separately.
   • Stop/branch: an account notice or payment/verification record wins over an outage hypothesis for that scope, even if a provider incident coexists. If delivery and settled records are healthy while reporting is stale/quarantined, classify reporting-only and keep the incident open until freshness/backfill is reconciled. [PR-P10][PR-P11][PR-P13][PR-P14][PR-P15][PR-P09][PR-P18]

4. Map local and shared dependencies before changing them.

   • Input: admin/identity graph, payment profile, domains/endpoints, pixel/dataset, catalog/feed, OAuth/token ownership, agency/vendor links, automation, and approvers; include vendor logs and common timestamps.
   • Owner: incident lead coordinates; asset owner approves containment; partner owner supplies logs.
   • Action: mark each dependency controlled, observed, provider-dependent, or unknown. For compromise, use a known-clean endpoint and review sessions, apps, tokens, extensions, and administrators without destroying evidence. Read back actual state after any script or integration action. [PR-P12][BC-S06][BC-S09][BC-S10][BC-S18]
   • Stop/branch: one shared manager, identity, payment, domain, feed, dataset, or vendor path means shared-dependency remains a live hypothesis. Stop before broad revocation, rotation, deletion, or relinking when persistence or blast radius is unknown. [RS-S17][RS-S18][RS-S23]

5. Contain one reversible risk, route officially, and accept recovery.

   • Input: approved hypothesis, evidence index, authorization, expected state, rollback condition, current first-party route, post-change access/permission diff, ledger reconciliation, event/conversion test, and monitored restart observations.
   • Owner: incident lead authorizes; executor performs one change; recorder logs read-back; asset owner signs access; finance and measurement owners sign residuals; lead closes scope.
   • Action: pause/reduce spend only within authority when unauthorized activity, material exposure, or unsafe automation is plausible; otherwise freeze nonessential edits. Navigate directly to the provider domain, preserve the case ID, and verify ownership, persistence, dependencies, finance, evidence, campaign/rule diff, event path, and monitoring.
   • Stop/branch: stop when read-back conflicts, blast radius expands, or a route requests secrets. Login, active campaign, green status, or case response alone is not recovery. Keep the incident open while an acceptance predicate is unknown or provider-dependent. [DRS-A01][DRS-A15][PR-P07][BC-S06][BC-S09][RS-S08]

Evidence to preserve

• UTC chronology with local time-zone context, owner, and every attempted action.
• Exact product/surface, account and object IDs, raw labels, detail IDs, status URLs, case IDs, and route shown in-account.
• Last-known-good/current exports for permissions, budgets, delivery, billing, reporting, events, and backend settlement.
• UI/API and second-admin comparisons; clean-device/network result; request IDs; DNS/TLS/HTTP or vendor logs where relevant.
• Shared-dependency and parent-child map; unavailable evidence and verification owner.
• Redacted, access-controlled copies under the applicable retention process. Never put passwords, MFA codes, cookies, full payment data, government IDs, or unrestricted keys in the register. [DRS-A01][RS-S03]

What not to do

• Do not infer an outage, fault, lost revenue, or reimbursement from zero spend, a blank dashboard, one login failure, or a green page.
• Do not repeatedly edit budgets, bids, payments, domains, feeds, or tracking while control-plane or reporting failure is plausible.
• Do not rotate identities, rent trusted accounts, create replacement accounts to bypass restrictions, cloak destinations, use anti-detect tools, forge records, or flood appeals. Meta has described action against restoration scams and rented trusted accounts. [PR-P07]
• Do not file an indiscriminate chargeback. Separate unauthorized activity, legitimate balance, and agency invoice mismatch; Google warns that reversing a legitimate balance can create suspension risk. [BC-S07][BC-S08]
• Do not send credentials, cookies, MFA codes, government IDs, full payment data, remote access, or scripts to unsolicited “support.” [DRS-A15][BC-S18]

When to escalate

Self-service: one surface and one account, clear owner access, no suspected unauthorized activity, intact evidence, and a current first-party route that answers the next action. Keep the case and run the acceptance gate.

Escalate: the incident crosses accounts/platforms, custody, finance, security, measurement, legal/entity, or vendors; evidence may be lost; unauthorized activity is active; or authority is unclear. Route enforcement/verification to the platform, suspected transactions to the bank/issuer, endpoint/session compromise to security responders, contract/billing rights to finance/counsel, and cross-tenant exposure to privacy/legal owners. No route guarantees an outcome or review time.

Stop/decline: evasion, forged evidence, credential surrender, concealed destination, indiscriminate dispute, guaranteed reinstatement, or a claim outside available authority and evidence.

FAQ

Does zero spend mean the platform is down?

No. It may reflect reporting, schedule, budget/payment, policy/verification, targeting, destination/feed, local integration, shared dependency, or a provider incident. Freeze scope and compare path-distinct signals. [RS-S07][PR-P21]

If the status page is green, is the account healthy?

No. Status pages are product-scoped observations and may miss account, API, regional, or unacknowledged incidents. Green does not clear payment, verification, enforcement, identity, or integration. [PR-P01][PR-P09][RS-S19]

What makes two signals independent?

Their failure paths differ. Name provider, identity, network, data, finance, and backend paths; do not count multiple views that all rely on the same provider response. This is an operating rule, not a statistical threshold. [RS-S17][RS-S18][RS-S19]

Can DNS evidence prove TikTok Ads stopped?

No. Cloudflare's January 2025 U.S. measurement is DNS evidence tied to a legal/policy interruption, not Ads Manager or auction telemetry. [PR-P22][PR-P25]

When is recovery accepted?

After authorized access/ownership, persistence and dependency review, separate finance/delivery reconciliation, preserved evidence, event/conversion test, monitored restart, and named sign-off. Login or a green dashboard alone is insufficient. Synthesis/inference. [DRS-A01][BC-S06][BC-S09]

Source appendix

Sources were accessed 2026-07-19. Check mutable platform routes and labels against the cited first-party pages for the affected account and region immediately before acting.

Mutable route reminder

• Re-check Meta, Google Ads, and TikTok labels/routes for the account and region before live use.
• Record eligibility, URL, and product scope from the current first-party route.