Direct answer
“Zero spend” is an observation, not a cause. Separate zero reported results, zero impressions, zero attributed conversions, and delivery failure. Freeze scope, time zone, IDs, and last-known-good export. Compare delivery data with report/API freshness, schedule, budget, payment, policy/verification, destination/feed, and incidents. A green status page does not clear an account; a blank report does not prove ads stopped. Use official route and restart only after delivery, measurement, finance, and access checks pass.
Who this is for
Fit: operators and executives managing high-spend Meta, Google Ads, or TikTok programs with no spend, impressions, reports, or attributed conversions.
Non-fit: not an appeal service, reinstatement promise, legal advice, or bypass guide. It does not diagnose from screenshots or prescribe universal bid, budget, or recovery fixes.
Decision model
Use four predicates, recorded separately:
| Predicate | What it means | What it does not prove |
|---|---|---|
| Zero reported results | The selected dashboard, report, or API returns no rows/results. | That no ads served. A filter, time zone, object scope, freshness problem, or API/report failure may be involved. |
| Zero impressions | An authorized delivery record for the defined scope shows no impressions. | The reason. Scheduling, budget/payment, policy/verification, targeting, feed/destination, auction, regional conditions, or an incident can all remain hypotheses. |
| Zero attributed conversions | The platform reports no conversions for its definition, window, and model. | That there were no visits, leads, orders, or settled outcomes. Event loss, consent, deduplication, attribution-window differences, modeled reporting, or downstream failures may explain the gap. |
| Delivery failure for frozen scope | Two dependency-distinct delivery signals show no serving for an authorized, eligible scope during an intended live window, after report freshness and configuration checks. | A provider-side root cause, reimbursement, restoration, or universal platform outage. |
Synthesis/inference: this diagnostic state machine pairs black-box symptoms with owned telemetry and preserves competing hypotheses; provider and user views can differ. [RS-S07][RS-S09][RS-S19]
Independence rule (Synthesis/inference): count failure paths, not views. Signals are dependency-distinct only when they do not share report backend, account scope/ownership, identity, payment, domain/catalog/feed, pixel/dataset, credentials/admin, vendor/token/automation, or policy exposure. Same-backend UI/API/export/second-admin views corroborate but do not establish state; unresolved sharing is unknown.
A compact decision tree:
NO SPEND / NO RESULTS OBSERVED
|
+-- Can the report/API be trusted for this scope and time window?
| NO -> quarantine the report; compare a raw delivery export, UI/API,
| and second authorized viewer. Do not call it delivery-zero.
|
+-- Does an authorized delivery record show impressions?
| YES -> delivery occurred; branch to billing, attribution, or reporting.
| NO/UNKNOWN -> check schedule, budget, payment, policy, verification,
| targeting, destination/feed, and recent changes.
|
+-- Do two dependency-distinct signals show no serving for the frozen eligible scope?
| YES -> classify delivery failure for frozen scope; root cause remains unknown.
| NO -> delivery failure remains suspected/unproven; resolve shared dependencies
| or preserve the conflict.
+-- Is there an account/region/product incident or provider notice?
YES -> preserve evidence, use official route, avoid repeated edits.
NO/UNKNOWN -> open one factual case if material; stop before risky changes.
Diagnostic or control sequence
- Open a factual record. Evidence/input: platform/surface, region/entity, IDs, message, first-seen UTC, time zone, and last-known-good export. Owner: incident lead/recorder. Action: record the symptom without a cause. Stop/branch: retrieve missing IDs, scope, or time before editing.
- Freeze the comparison window. Evidence/input: filters, attribution window, schedule, budget period, currency, and time zone. Owner: measurement owner. Action: define one cohort and preserve the query/export. Stop/branch: label differing windows/scopes “not comparable”; do not infer zero delivery.
- Test reporting before delivery. Evidence/input: raw export, dashboard, authorized API, query parameters, freshness, and second viewer. Owner: measurement owner. Action: compare UI/API and report/export for stale, missing, or filtered data. [PR-P09][PR-P18] Stop/branch: quarantine unavailable or contradictory evidence and preserve the conflict.
- Establish the served-delivery predicate. Evidence/input: impressions, clicks, cost, status, and frozen cohort. Owner: operations executor. Action: classify report-zero, impression-zero, or delivery observed. Stop/branch: if impressions or cost exist, route to attribution, billing, or reporting.
- Check intended eligibility and timing. Evidence/input: schedule, dates, time zone, budget/bids, targeting, approval, inventory, and change ledger. Owner: campaign owner. Action: identify a configuration explanation or record none. Stop/branch: do not change settings while state is unrecorded; stop if unauthorized or rollback is unclear.
- Check payment, policy, and verification separately. Evidence/input: notices, billing/transactions, authorization, verification requests, policy references, and region/entity. Owner: finance; asset/legal owner. Action: mark observed, clear, or unknown; use displayed first-party route/labels for the affected account and region. [PR-P03][PR-P04][PR-P05][PR-P10][PR-P11][PR-P13][PR-P14][PR-P15][PR-P16] Stop/branch: preserve records and use the official route for provider review.
- Check destination, feed, and event dependencies. Evidence/input: landing, catalog/feed, pixel/CAPI/Events API/tags, consent, deduplication, analytics, CRM, and backend. Owner: measurement/destination owners. Action: distinguish delivery-zero from downstream gaps. Stop/branch: if delivery exists but events/outcomes are absent, classify measurement/settlement risk and freeze instrumentation until one cohort is defined. [RS-S07][RS-S08]
- Check product, regional, and partner signals. Evidence/input: status/history, region/network, manager relationships, API/vendor logs, and customer symptoms. Owner: incident/partner owner. Action: compare dependency-distinct paths. Synthesis/inference: heuristic, not a statistical guarantee. Historical boundaries: Meta’s 2024 report covers login/Ads-surface disruption, not account spend loss [PR-P17]; Google’s August 2024 report covers data isolation, not universal serving loss [PR-P18]; Google’s March 2025 report says some campaigns stopped, with cause/scope unclear [PR-P21]; Cloudflare’s January 2025 U.S. TikTok DNS observation is infrastructure evidence, not Ads telemetry [PR-P22]. Stop/branch: restrict sharing and escalate for cross-tenant evidence; do not keep querying or distributing it.
- Classify delivery failure cautiously. Evidence/input: frozen delivery export, authorized views/API, configuration, payment/policy/verification, and provider/region signals. Owner: incident lead. Action: record “delivery failure for frozen scope” only when two dependency-distinct signals agree an eligible live scope did not serve. Shared dependency means “suspected” or “unproven.” Root cause remains unknown; blank report, green status, or anecdote is insufficient. Synthesis/inference. [RS-S07][RS-S19]
- Contain one reversible risk, then route officially. Evidence/input: authorization map, before-state export, suspect changes, and first-party route. Owner: asset owner approves; executor acts; recorder reads back. Action: pause/reduce only for plausible unauthorized activity, exposure, or unsafe automation; submit one factual case. Stop/branch: stop on unexpected read-back, expanded blast radius, or sensitive-credential requests. [RS-S03][PR-P03][PR-P07][PR-P10][PR-P13][PR-P15]
- Reconcile separate ledgers. Evidence/input: billed, served, attributed, analytics/events, backend-settled, bank/card, and agency records. Owner: finance/measurement owners. Action: match entity, IDs, period, currency, time zone, and cohort; record residuals. Stop/branch: do not reverse a legitimate balance because a report is empty; unauthorized, platform-balance, and agency-invoice branches differ. [PR-P11][RS-S08]
- Use an explicit restart decision. Evidence/input: provider notice/case, corrected configuration, access/dependency review, ledgers, event test, and before-state. Owner: asset, finance, and incident owners. Action: authorize a limited monitored restart. Stop/branch: no restart if ownership, payment authority, policy/verification, destination, event path, or rollback is unknown; green is not recovery. [RS-S03][RS-S07][RS-S09]
Restart acceptance checks
Do not mark the incident recovered until the owner records each applicable check:
- Delivery predicate passes for the frozen scope; impressions and cost are observed where the restart intends serving.
- Access, owner, partner, payment authority, policy/verification state, schedule, budget, destination, feed, and shared dependencies are reviewed.
- Billed, served, attributed, analytics, backend, bank/card, and agency records are reconciled or residuals have owners and dates.
- A test event or conversion follows the intended path into the defined record; consent, deduplication, and latency limits are documented.
- Campaign/rule/automation state matches the preserved before-state, with no unexpected changes.
- Restart is limited, monitored, reversible, and has a written stop condition.
- Asset owner, finance owner, and incident lead sign scope, residual provider dependencies, and closure date.
This is an operating synthesis, not a provider recovery standard. [RS-S03][RS-S07][RS-S09]
Evidence to preserve
- Incident ID, reporter, first-seen UTC/local time, region, legal entity, symptom, platform/product surface, account/portfolio/manager/campaign/ad IDs, labels/errors, request ID, and case ID.
- Frozen query: date range, time zone, filters, attribution window, currency, object scope, export timestamp, and API/UI result.
- Last-known-good/current exports, budget/schedule/status, creative/targeting, payment/policy/verification/feed state, and recent changes with actor, timestamp, old/new value, approval, and rollback.
- Second-admin/API/status observations; customer/analytics/backend symptoms; billing, bank/card, agency, served-cost, attribution, and settled-outcome records.
- Event samples, consent/matching/deduplication, destination/catalog/feed health, unavailable-data notes, every attempted action, read-back, approver, and stop decision.
Screenshots can orient a reviewer but do not replace exportable records. Preserve evidence when safe and feasible before revoking, deleting, relinking, or rebuilding shared objects, subject to privacy and retention rules; urgent authorized containment must not be delayed. [RS-S03][RS-S15]
What not to do
Do not call a blank report a delivery outage, a zero-conversion report a revenue loss, or status silence proof no incident occurred. Do not repeatedly edit, blindly widen targeting, rotate identity/payment, create replacement or rented accounts, use cloaking/anti-detect tools, forge documents, flood appeals, or reverse a legitimate balance. Synthesis/inference safety rule: these are not diagnostic remedies and can expand exposure or evade controls. Never give passwords, MFA codes, cookies, government IDs, payment data, browser data, remote access, or scripts to an inbound “recovery” contact. Meta has described fake restoration services and rented trusted accounts [PR-P07]; Google’s guidance is provider-specific [PR-P10][PR-P11].
When to escalate
Use self-service when one authorized owner can reproduce a known-scope symptom, no compromise/provider decision is pending, and one reversible action has clear rollback. Escalate through the platform route for suspension, payment/transaction, verification, policy, cross-tenant, or provider risk; escalate internally for security, finance, legal/privacy, multiple owners, shared dependencies, or missing evidence.
A specialist can organize evidence and acceptance checks; no specialist controls a provider decision. Do not promise timing, restoration, reimbursement, ROAS, or recovery.
Official-route use
Official route identities are source-locked: Meta review, business verification, failed payment, and status; Google Ads Status, suspension/appeal, and billing/payment; and TikTok Account Health/suspension, business verification, transaction appeals, and advertising policies. See the source appendix for exact first-party URLs and citation keys.
Before acting, an authorized owner must open the current first-party route for the affected account and region and follow displayed labels. Public pages establish route identity; they do not guarantee account-specific labels, eligibility, timing, document requirements, approval, or outcome. Retrieve provider incident objects or account case IDs for delivery loss; confirm refund/credit/support/retention terms with provider or contract owner.
FAQ
Is zero spend proof that ads did not serve? No. Test report freshness, filters, scope, and time zone against raw delivery data; zero reported results and zero impressions differ.
If impressions are zero, is the platform down? Not necessarily. Check schedule, budget, payment, policy/verification, targeting, destination/feed, region, changes, and incidents; delivery failure remains a hypothesis until dependency-distinct signals agree.
If attributed conversions are zero, should tracking change immediately? No. Compare delivery, event arrival, consent, deduplication, attribution window, analytics, CRM, and settled outcomes for one frozen cohort.
Does a green Meta, Google, or TikTok status page clear the account? No. It is one product-scoped signal, not dependency-distinct delivery proof; compare exports, authorized view/API data, and customer telemetry. [PR-P01][PR-P02][PR-P09][RS-S19]
What counts as recovered? Not a green dashboard or restored login alone. Require delivery, ownership/dependency review, finance reconciliation, an event test, staged monitoring, and signed closure. Synthesis/inference. [RS-S03][RS-S07][RS-S09]
Source appendix
All sources were accessed 2026-07-19. Before acting, an authorized account owner must open the current first-party route for the affected account and region and re-check mutable platform pages and account-specific routes.
| Key | Source title; author/publisher; publication date | URL |
|---|---|---|
| PR-P01 | “Status and outages of Meta business products”; Meta; live/undated | https://metastatus.com/ |
| PR-P02 | “About Meta Status Page”; Meta Business Help Center; undated | https://www.facebook.com/business/help/1171568854968373 |
| PR-P03 | “Request a review if you are restricted from advertising on Meta platforms”; Meta; undated | https://www.facebook.com/business/help/530209463124901/ |
| PR-P04 | “Verify Your Business in Meta Business Suite”; Meta; undated | https://www.facebook.com/business/help/2058515294227817/ |
| PR-P05 | “Fix a failed payment issue on Meta”; Meta; undated | https://www.facebook.com/business/help/268196136699959/ |
| PR-P07 | “Meta Takes Legal Action Against Scam Advertisers”; Meta Newsroom; Meta; 2026-02-26 | https://about.fb.com/news/2026/02/meta-takes-legal-action-against-scam-advertisers/ |
| PR-P09 | “History | Google Ads Status Dashboard”; Google; live/undated | https://ads.google.com/status/publisher/summary |
| PR-P10 | “Google Ads account suspensions overview”; Google Ads Help; current/undated | https://support.google.com/adspolicy/answer/9841640?hl=en |
| PR-P11 | “Billing and payment suspensions”; Google Ads Help; current/undated | https://support.google.com/adspolicy/answer/13704200?hl=en |
| PR-P13 | “About suspended ad accounts on TikTok”; TikTok for Business; updated June 2026 | https://ads.tiktok.com/help/article/account-suspensions?redirected=1 |
| PR-P14 | “How to verify your business on TikTok”; TikTok for Business; updated May 2026 | https://ads.tiktok.com/help/article/about-business-verification?aadvid=72391499277 |
| PR-P15 | “About transaction-related appeals”; TikTok for Business; updated July 2026 | https://ads.tiktok.com/help/article/about-transaction-related-appeals |
| PR-P16 | “TikTok Advertising Policies”; TikTok for Business; updated August 2025 | https://ads.tiktok.com/help/article/tiktok-advertising-policies?lang=en&redirected=2 |
| PR-P17 | “Facebook And Instagram Hit By Massive Outage”; Roger Montti, Search Engine Journal; 2024-03-05 | https://www.searchenginejournal.com/facebook-and-instagram-hit-by-massive-outage/510267/ |
| PR-P18 | “Google Ads Experiencing Outage Impacting Key Features [Updated]”; Matt G. Southern, Search Engine Journal; published 2024-08-01, updated 2024-09-19 | https://www.searchenginejournal.com/google-ads-experiencing-outage-impacting-key-features/523624/ |
| PR-P21 | “Google Ads stop running for some advertisers”; Barry Schwartz, Search Engine Land; 2025-03-02, updated 2025-03-03 | https://searchengineland.com/google-ads-stop-running-for-some-advertisers-452864 |
| PR-P22 | “The fall and rise of TikTok (traffic)”; João Tomé, Cloudflare Blog; published 2025-01-21, modified 2026-07-15 | https://blog.cloudflare.com/the-fall-and-rise-of-tiktok-traffic/ |
| RS-S03 | “Cybersecurity Incident & Vulnerability Response Playbooks”; CISA; U.S. government; 2021 (PDF served from 2024 path) | https://www.cisa.gov/sites/default/files/2024-08/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf |
| RS-S07 | “Monitoring Distributed Systems”, chapter 6; Rob Ewaschuk, edited by Betsy Beyer; Google SRE; 2017 | https://sre.google/sre-book/monitoring-distributed-systems/ |
| RS-S08 | “Service Level Objectives”, chapter 4; Chris Jones, John Wilkes, Niall Murphy, Cody Smith; Google SRE; 2017 | https://sre.google/sre-book/service-level-objectives/ |
| RS-S09 | “Managing Incidents”, chapter 14; Andrew Stribblehill; Google SRE; 2017 | https://sre.google/sre-book/managing-incidents/ |
| RS-S15 | “How Good is Your Data? Investigating the Quality of Data Generated During Security Incident Response Investigations”; George Grispos, William Bradley Glisson, Tim Storer; arXiv; 2019-01-11 | https://arxiv.org/abs/1901.03723 |
| RS-S19 | “Characterizing User and Provider Reported Cloud Failures”; Mehmet Berk Cetin, Sacheendra Talluri, Alexandru Iosup; arXiv; 2021-10-23 | https://arxiv.org/abs/2110.12237 |
Related resources
- TikTok Ads Not Delivering? Diagnose Zero ImpressionsTikTok ads approved but not delivering or spending? Check delivery status, billing, schedule, audience, bid, budget, and creative before making changes.
- Facebook Ads Stopped Delivering — Insufficient Funds FixYour Facebook ads stopped delivering after a payment failure or insufficient funds. Here's what's actually happening, whether it resets your learning phase, and how to fix it.
- Google Ads Suspension Recovery — The Full RoadmapA step-by-step roadmap for recovering from a Google Ads suspension: how to triage the suspension type, which appeal channel to use, realistic timelines, and what to do if the appeal fails.
- Google Ads Account Suspended for Billing — Fix GuideYour Google Ads account has been suspended due to a billing issue — failed payment, suspected fraud, or expired card. Here's how to identify the exact issue and get your account back.
- Meta Pixel Not Firing — Troubleshooting GuideYour Meta Pixel is not firing or firing inconsistently. Here's how to diagnose the issue, fix broken tracking, and restore your conversion data and retargeting audiences.
Contact AdsInfra
Send a message about this resource before making a high-impact change.