Meta Ads Delivery Outage July 16, 2026: Timeline & Why Most Monitoring Missed It
Meta's Ads Delivery system was disrupted for over two hours on the morning of July 16. The incident itself is a familiar story — but this time we measured something new: Meta's own status feed lagged its dashboard by 90 minutes.
Quick summary
- Incident date: July 16, 2026 (5:40 AM - 7:47 AM ET / 2:40 AM - 4:47 AM PT)
- Acknowledged duration: ~2 hours 7 minutes (the outage started before Meta's first update)
- Service affected: Ads Delivery
- Severity: High disruptions
- Notable: Meta's RSS feed published the incident ~90 minutes after the status dashboard showed it
Official timeline
Meta posted the incident to its status dashboard at 09:40 UTC — 5:40 AM ET, in the middle of the European advertising morning (10:40 AM in London, 11:40 AM in Paris).
| UTC | ET (America/New_York) | PT (America/Los_Angeles) | Status |
|---|---|---|---|
| 2026-07-16 09:40 | July 16, 5:40 AM | July 16, 2:40 AM | High disruptions - Ads Delivery |
| 2026-07-16 11:47 | July 16, 7:47 AM | July 16, 4:47 AM | Resolved |
Meta's official statements
"We are recovering from an earlier outage that caused disruptions in ad delivery and services are in the process of being restored. We apologize for any inconvenience that this may have caused."
Resolution: "We have recovered from an earlier outage impacting ad delivery across our platform, and services have now been restored."
Read that first statement again: Meta's opening update — tagged "High disruptions" — already describes an "earlier outage" that services were recovering from. The disruption began before 5:40 AM ET; that's just when Meta acknowledged it publicly. The true impact window is longer than the official 2 hours 7 minutes.
The 90-minute blind spot: dashboard vs. RSS
Here's the part nobody else measured. Meta's status page (metastatus.com) publishes incidents in two places: the dashboard itself, and an RSS feed that most monitoring tools — including status aggregators — poll for updates. On July 16, those two sources told very different stories:
Status dashboard: incident visible at 09:40 UTC
The data source that renders metastatus.com carried the "High disruptions" post — with its full timestamp and description — from the moment Meta published it.
RSS feed: entry appeared at ~11:11 UTC
The RSS entry for the same incident was stamped 11:11 UTC — 91 minutes after the dashboard. Anything monitoring Meta via RSS was blind for the first hour and a half, which covered most of the outage. Thirty-six minutes later, Meta declared the incident resolved.
The wording trap
Meta's active update was worded in recovery language ("services are in the process of being restored") while still carrying the "High disruptions" severity tag. Monitoring tools that classify incidents by keywords in the description — rather than by Meta's explicit severity tag — read that update as already resolved and never raised an alert at all.
Why this matters: for a 2-hour incident, a 90-minute feed delay isn't a detail — it's the difference between reacting during the outage and reading about it afterwards. As of July 16, AdStatus monitors Meta's dashboard data source directly, in addition to the RSS feeds, and treats Meta's severity tag as the source of truth. Alerts now fire when the dashboard updates, not when the feed catches up.
Who was exposed: a tale of two time zones
| Region | Local window | Exposure |
|---|---|---|
| Europe | 10:40 AM - 12:47 PM (London) | Peak morning delivery hours — campaigns disrupted mid-flight |
| US East | 5:40 AM - 7:47 AM | Overnight/early ramp — most teams woke up after resolution |
| US West | 2:40 AM - 4:47 AM | Overnight — invisible without monitoring or a morning spend review |
Early-morning US incidents are the sneakiest kind: by the time American teams open Ads Manager, the status page shows green and the only evidence is in the hourly spend and delivery data. European advertisers, meanwhile, took this one square in the face during active trading hours.
What you should check now
- 1 Review the hourly breakdown for July 16: In Ads Manager, break down delivery and spend by hour between 5:40 AM and 7:47 AM ET (and the hours just before — remember, the outage started earlier than the acknowledgment).
- 2 Look for both underspend and catch-up spikes: Delivery outages suppress spend during the window, then pacing systems often compensate aggressively after recovery. A delivery dip followed by a spend spike is the classic signature.
- 3 Validate conversion data for the window: Delivery disruptions frequently come with attribution gaps. Cross-check July 16 morning conversions against your backend numbers before drawing performance conclusions.
- 4 Document anything anomalous: Screenshot hourly charts now while the data is fresh. If you later file a refund or credit claim, you'll need proof tied to the exact incident window.
For the full breakdown of budget overspend mechanics during Ads Delivery outages — including Meta's 75% overspend buffer and why refunds usually fail — see our March 16 incident analysis.
Ads Delivery: 2026's most fragile surface
This is at least the third significant Ads Delivery incident of 2026, and they share a pattern: high severity, roughly two-hour acknowledged windows, and terse two-post timelines (one acknowledgment, one resolution).
| Date | Incident | Acknowledged duration |
|---|---|---|
| January 22 | Ads Delivery disruption | ~2 hours |
| March 16 | Ads Delivery outage (evening US) | ~1.5 hours |
| July 16 | Ads Delivery outage (this incident) | ~2 hours 7 minutes |
Get alerts from the dashboard, not the delayed feed
Ad Status Monitor now reads Meta's status dashboard data source directly — the same data metastatus.com renders — so Slack and Teams alerts fire when Meta acknowledges an incident, not 90 minutes later when the RSS feed catches up.
- Monitors Meta, Google, Microsoft, Pinterest, Amazon, Shopify, and AI platforms
- 5-minute check intervals, instant Slack or Teams notifications
- 14-day free trial, no card required