Recent Outages → Money Impact (Last 14 Days)
A short living brief for CTOs, SREs, and founders: what broke, how long it lasted, who felt it, and how to estimate your money impact with TechImpact tools. Simple English. Source links. No fake “official vendor losses.” Hub: Reliability Money Toolkit.
1. How to read this brief
Outage news often mixes three different numbers: vendor status-page duration, user-report spikes, and your private business loss. This page keeps those separate on purpose.
- Facts: timing, services, and root-cause notes from public reports (linked).
- Blast radius: who felt it downstream (education apps, identity, AI platforms, and so on).
- Money model: an ILLUSTRATIVE scenario you can open in our calculators and then replace with your inputs.
If you only need the suite map, start at the Reliability Money Toolkit. If you need formulas and allowed-downtime tables, use the SLA uptime → downtime reference.
2. 14-day snapshot (as of 23 Jul 2026)
| Incident | When (UTC / noted) | Duration (reported) | Confidence |
|---|---|---|---|
| AWS CloudFront VPC Origins | 16 Jul 2026, ~07:45–11:18 UTC | ~3 h 33 m | High (AWS + secondary reports) |
| Google Cloud europe-west4-a | 15–16 Jul 2026 | ~14 h 55 m (zone / listed services) | High (Google incident page) |
| Meta (Facebook / Instagram / WhatsApp) | 19 Jul and 22 Jul 2026 (GMT afternoon spikes reported) | Less certain — user reports; no clear Meta post-mortem at writing | Medium (public user reports) |
Duration confidence matters for money models. A clean vendor timeline is easier to plug into a calculator. A messy consumer-report spike needs a low / mid / high range instead of one false exact number.
Most relevant for reliability planning this window: (1) CloudFront VPC Origins — narrow control-plane failure, wide cascade; (2) GCP europe-west4-a — long zone / facility power+cooling event; (3) Meta — dependency risk outside your VPC (ads, support, messaging).
3. AWS CloudFront VPC Origins — 16 Jul 2026
What happened
On 16 July 2026, Amazon CloudFront customers using VPC Origins saw elevated global 5xx errors for roughly 3 hours 33 minutes (about 07:45–11:18 UTC, matching common public timelines). Distributions that did not use VPC Origins were generally not in the same failure path.
Public summaries describe a control-plane / routing-capacity problem tied to the connection-management
fleet for private VPC origins. Capacity stress in a Frankfurt availability zone
(euc1-az2 / eu-central-1) interfered with loading and distributing routing
configuration to CloudFront’s global edge processors. The technical footprint was narrow (one origin type);
the user footprint was wide because many products put CloudFront in front of private backends.
Who felt it
Downstream reports named education and collaboration platforms (for example Canvas and Blackboard), AI and ML platforms (for example Hugging Face), identity and access tooling (for example Frontegg), networking vendor cloud services (for example Ubiquiti), and other internet-facing apps. Cascade risk is the lesson: if your identity provider or CDN path fails, healthy application servers can still look “down” to end users.
Sources
- IncidentHub: July 2026 AWS CloudFront / VPC Origins summary
- TechTimes: cascade impact and Frankfurt AZ control-plane notes
- The Register: AWS status wording and workaround notes
- Also cross-check AWS’s own Health Dashboard posts for the official “internal constraint” wording on the VPC Origins connection fleet.
How to model $ impact (ILLUSTRATIVE)
ILLUSTRATIVE assumptions only — not AWS’s loss, not your loss until you edit the numbers:
- Revenue at risk: $10,000 / hour
- Duration: 3 h 33 m (match the reported window)
- Refund rate: 5% · Conversion drop: 10%
- Affected employees: 40 at $55 / hour
- Similar incidents / year for annualizing: 4 · Currency: USD
Open a ready scenario: Downtime Cost Calculator (CloudFront-length scenario) .
Replace rev, refund, conv, emp, and cost
with your values. Keep h/m if you want this incident’s length.
Quick check before you trust the total:
Revenue piece ≈ revenue_per_hour × (hours + minutes/60)
Example: 10,000 × (3 + 33/60) ≈ 10,000 × 3.55 ≈ $35,500 revenue line only — before refunds, conversion, and productivity.
Also map the time budget for your SLA month with the Allowed Downtime Calculator and compare recovery targets in the RTO/RPO Impact Calculator. If you sell uptime to customers, estimate credits in the SLA Penalty Calculator.
4. Google Cloud europe-west4-a — 15–16 Jul 2026
What happened
Google Cloud reported a multi-hour disruption in europe-west4-a (Netherlands) after a power problem that led to a cooling failure. Ambient temperatures rose quickly; Google described a proactive shutdown of hosts, storage, and network gear to protect equipment and customer data. Public summaries put the zone-level impact at about 14 hours 55 minutes.
This was not “all of Google Cloud globally.” It was a zone / facility-class event with a focused product list — still painful for anyone who pinned critical workloads to a single AZ without a tested failover path.
Who felt it
Services commonly listed in the incident materials include Google Cloud VMware Engine (GCVE), Bare Metal Solution, and Google Cloud NetApp Volumes. Teams running hybrid / VMware / bare-metal / NetApp-dependent storage in that zone saw the longest pain. Broader GCP products in other zones were not the same story — but multi-AZ assumptions only help if you actually tested failovers.
Sources
- Google Cloud incident 3BvH3LVGcupoYqV6F4Nw
- Data Center Dynamics: Netherlands facility power + cooling (~14h 55m)
- Computing.co.uk: power/cooling and resilience context
How to model $ impact (ILLUSTRATIVE)
ILLUSTRATIVE assumptions only — not Google’s loss:
- Same starter business inputs as above ($10k/hour, 5% refunds, 10% conversion drop, 40 staff @ $55/hour, 4 incidents/year)
- Duration set to 14 h 55 m to match the widely reported window
Open a ready scenario: Downtime Cost Calculator (europe-west4-a-length scenario) .
Long outages change the story: overnight idle hours, partial restore waves, and data rebuild work. After the base revenue line, add overtime and restore labor separately if those were real for you.
Rough revenue line only: 10,000 × (14 + 55/60) ≈ 10,000 × 14.9167 ≈ $149,167
That is still only one slice. Storage rebuild, VMware recovery, and customer credits can dominate for GCVE / NetApp-heavy estates.
For recovery planning after a zone loss, pair the money model with RTO vs RPO decision matrix and RTO/RPO Impact Calculator. Check whether your SLA month still has room using calendar-month downtime tables and Allowed Downtime.
5. Meta (Facebook / Instagram / WhatsApp) — 19 & 22 Jul 2026
What happened
On Wednesday afternoon 22 July 2026 (GMT), public outage trackers and news desks reported widespread user problems across Meta apps — Facebook, Instagram, and WhatsApp (and often Messenger in the same wave). Common symptoms in user reports included forced logouts, “account temporarily unavailable” style messages, failed feed refreshes, and messaging failures. Several outlets also described this as a second widespread interruption within about 72 hours of a similar wave around 19 July 2026.
Duration is less certain than the cloud incidents above. Report spikes on 22 Jul clustered around early afternoon GMT (~13:00); recovery was gradual in public trackers. At the time of this brief, Meta had not published a clear, detailed post-mortem comparable to a cloud status incident page. Some analysts mentioned possible DNS-related symptoms; treat that as an unconfirmed hypothesis, not a settled root cause.
Who felt it — and why it matters for B2B teams
This is mainly a consumer blast-radius story. Still, many businesses depend on Meta surfaces for:
- Customer support and community replies
- Login / social identity shortcuts
- Ads and landing-page traffic
- WhatsApp Business messaging
If your checkout stayed up but your ad traffic or WhatsApp support channel died, your “site uptime” graph can look healthy while revenue and support queues still suffer. That is dependency risk — the same class of lesson as an identity-provider cascade during the CloudFront event.
Sources
- Manchester Evening News: afternoon GMT user reports (22 Jul)
- Geo.tv: timeline notes and DNS hypothesis (unconfirmed)
- TechJuice: second outage-in-72-hours framing
- Cross-check Downdetector-style trackers and Meta’s status page; do not invent a precise end time if Meta did not publish one.
How to model $ impact (ILLUSTRATIVE)
ILLUSTRATIVE — duration deliberately conservative because the public end time is fuzzy:
- Model a 1 h 30 m “core disruption” case for planning talks (not a claim of Meta’s official duration)
- Same starter money inputs: $10k/hour, 5% refunds, 10% conversion drop, 40 staff @ $55/hour, 4×/year
- If Meta is only an ads / support channel for you, reduce
revto the share of revenue that actually depends on those channels
Open a ready scenario: Downtime Cost Calculator (1h 30m illustrative Meta-dependency case) .
Run a second link with h=3&m=0 if you want a stress case.
Write both results in the same slide: “core” vs “stress.” Do not pretend one number is official.
For teams that pause ads when landing pages fail, also see n8n watchdog for landing pages. For credit claims against your vendors (not Meta consumer apps), use How to file an SLA service credit claim.
6. What we skipped this window
Not every status blip belongs in a money-planning brief. For this 14-day refresh we intentionally did not deep-dive:
- OpenAI / ChatGPT (around 22 Jul 2026): reports of elevated errors on file uploads and image generation. Useful if you ship AI features, but not a primary cloud-zone or CDN cascade lesson for most CTO/SRE money reviews this week.
- Twilio regional SMS/voice path issues: important for telephony-heavy products; too narrow for a general reliability-money snapshot unless WhatsApp/SMS is your checkout path.
- Routine CDN edge maintenance windows with traffic already rerouted — noise for this page.
If your product depends on one of those paths, still model it: pick duration from the status page,
set rev to the revenue share that uses that dependency, and open Downtime Cost.
7. Methodology — what we do not claim
TechImpact.online does not claim official AWS, Google, Meta, or other vendor financial losses. We also do not invent a single “industry average cost per minute” and apply it to every reader.
What we do show:
- Public facts: timing, services, and linked sources.
- Honest uncertainty: when duration or root cause is unclear, we say so.
- A repeatable estimation method for your loss: revenue rate × duration, plus refunds, conversion effects, and productivity.
- Shareable calculator URLs so a team can debate the same scenario.
Core downtime-cost idea (simplified):
total ≈ revenue_loss + refund_costs + productivity_loss + other labeled add-ons
revenue_loss ≈ revenue_per_hour × duration_hours
Full open formulas live in the SLA uptime → downtime reference (methodology). Worked money examples live in real-world downtime cost examples.
SLA credits are a separate track. A vendor may owe a small invoice credit while your business loss is large — or the reverse, if you had little traffic during the window. Always model credit and business impact as two columns, not one blended fantasy number.
8. Update policy
This is a living reference. We refresh it manually when a major outage offers a clear planning lesson (new cascade pattern, long zone failure, or wide consumer dependency shock). We do not promise daily scraping. The “last 14 days” framing is a practical window for on-call and exec reviews — not a guarantee that every small regional blip appears here.
When we refresh, we update the article date, the snapshot table, and the illustrative calculator links. Older incidents may move into other guides (for example Starlink lessons in business continuity consulting).
Found an error in timing or a better primary source? Contact us — we correct public mistakes.
10. FAQ
Does TechImpact claim official vendor losses?
No. We summarize public incident reports and show how a team estimates its own loss with labeled illustrative assumptions.
How often is this brief updated?
Manually, when a major outage is useful for planning lessons. Check the “Updated” date at the top of the page.
What should I change in the sample links?
Change revenue per hour, refund %, conversion drop, employee count, hourly staff cost, and incidents per year. Keep duration close to the incident when that is the point of the exercise.
Why include Meta next to cloud outages?
Because dependency risk is not only “our VPC.” Ads, login, and messaging can fail while your servers stay green.
Is an SLA credit the same as downtime cost?
No. Credits are usually capped invoice reductions. Downtime cost is your business impact. Model them in two columns.
Which tool should I open first?
Money impact → Downtime Cost. Time budget → Allowed Downtime / Cost of Nines. Recovery targets → RTO/RPO. Credits → SLA Penalty. Overview → Reliability Money Toolkit.
Next step
Reliability Money Toolkit Downtime Cost Calculator Open methodology All guides