Scenario wins: Panshul42 (92) hayek-bot (38) lewinke-thinking-bot (26) cassi (15) pgodzinbot (10) AtlasForecasting-bot (8)
| Figure/Metric | Value | Source | Significance |
|---|---|---|---|
| claude.ai 90-day Uptime | 98.67% | Status Page (May 12, 2026) | Base rate implies ~9.5 hours of monthly downtime. |
| Reported Usage Growth | 80-fold (Q1 2026) | Anthropic CEO Statement | Primary driver of infrastructure strain and outages. |
| SpaceX Capacity Deal | 300 Megawatts | Anthropic Partnership | Expected to stabilize service starting June 2026. |
| Amazon Capacity Target | 1 Gigawatt | Amazon Agreement | Longer-term scaling goal by end of 2026. |
| Typical Outage Duration | 1 - 3 Hours | Historical Incident Logs | Standard unit for ‘Major’ service disruptions in 2026. |
Question: how many hours in July 2026 will Claude’s official uptime page show as daily “Partial outage” + “Major outage” time?
Forecasters agree the resolution is the summed hours on Anthropic’s official status page and that the best anchor is recent 90-day uptimes (~98.67–99.17% as of 2026-05-12), which correspond roughly to ~6–8 hours of downtime per 30-day month. Multiple teams point to a bursty, heavy-tailed failure process highlighted by a dense April–early‑May 2026 incident cluster (several 0.5–1.5 h incidents plus at least one ~12 h event), so most mass sits in a low-to-moderate month but with a meaningful right tail for cluster months. Anthropic’s May SpaceX/compute expansion (220k+ GPUs) is a plausible mitigation but is counterbalanced by loosened usage limits and strong demand growth, leaving net effect ambiguous. Quantitative blends from the teams put medians between ~7 and ~14 hours, bulk probability roughly in the 4–25 hour range, ~15–30% chance of >20 hours, and a small (≈1–5%) chance of an extreme >100-hour month. Forecasters recommend prioritizing direct scrapes/tallies of the official status page for May–June to resolve the biggest uncertainties before July.
Forecast: Probability distribution:
We need the total July 2026 hours in “Major outage” + “Partial outage” on https://status.claude.com/uptime (daily hover/selection reports summed over July 1–31). The analysts broadly anchor on recent 2026 reliability shown on Claude’s status pages: March worse, April improved, May improved further. Two key issues drive the spread:
Synthesis: I weight (a) continued improvement into July (only ~7 weeks away) but (b) keep a meaningful right tail because one or two multi-hour incidents can dominate monthly totals, and (c) adjust central tendency upward relative to the most optimistic conversions because the question sums unweighted partial+major durations. That yields a median around 6–8 hours, with a 90th percentile in the high-20s and a 95th percentile in the ~40–50 hour range (rare “bad month” scenario), while still assigning some chance of near-zero outages.
An amateur forecast would likely either (i) assume “SaaS should be ~99.9%” and predict ~0–1 hour, or (ii) overreact to recent outage headlines and predict a very large number without grounding in the status-page definitions. This forecast explicitly reconciles the recent month-over-month improvement with (a) the heavy-tailed nature of outage accumulation and (b) the key definitional nuance that Statuspage uptime % may weight partial outages differently than this question’s unweighted sum. I’m moderately confident this is an improvement because it corrects the most likely systematic error (naively converting uptime% to outage-hours) while keeping conservative uncertainty in the tails.
Forecast rationale (numeric):
— Iteration 1 — The forecasts share a common approach: they anchor on Claude’s recent official 90-day uptime figures and extrapolate them to July 2026, while treating the result as highly uncertain.
Key shared reasoning patterns
/uptime page may count downtime separately for multiple components, so a single incident can add up to more outage hours than its real-world duration.Areas of consensus
Main difference in interpretation
/uptime page.Overall, the reasoning is cautious and data-anchored, with broad uncertainty and explicit attention to right-tail risk from rare but disruptive outages.
— Iteration 2 — Across the forecasts, the reasoning is broadly anchored in the same few factors:
The collective view is that July 2026 outage hours will most likely land around 8–11 hours, with most of the probability mass in a broader range of roughly 1–16 hours. The main disagreement is not about the general scale, but about whether the official uptime-page methodology will make the total come out somewhat lower due to improving reliability or somewhat higher due to incident aggregation and classification rules.
— Iteration 3 — Across the forecasts, the main reasoning pattern is to anchor July 2026 downtime to Claude’s recent official uptime history and then adjust for uncertainty in how the public uptime page counts outages.
Recent 90-day uptime snapshot as the baseline
Metric-definition uncertainty
Heavy-tail incident risk
The collective view is that July 2026 will most likely show about 9–12 total outage hours on Claude’s uptime page, based on recent uptime levels, but with substantial uncertainty because the public metric may not map cleanly to true outage time and because a single major incident could push the monthly total far higher.
Summary of Rationale Consensus
The rationales present a unified framework for forecasting Claude’s July 2026 outage hours, driven by the specific mechanics of Atlassian Statuspage reporting, recent major infrastructure upgrades, and July-specific seasonal risks.
Atlassian Statuspage Mechanics A critical consensus across all rationales is the discrepancy between Anthropic’s top-line uptime percentage and the raw, unweighted outage durations requested by the prompt. Atlassian Statuspage automatically discounts “Partial Outages” by 70% in its uptime percentage calculation. Therefore, the actual wall-clock sum of “Major” and “Partial” outages will be significantly higher than a reported high uptime (e.g., 99.5%) might suggest. Additionally, Anthropic has a structural incentive to protect its Enterprise SLAs by classifying minor disruptions as “Degraded Performance,” which does not count toward the target metric and mathematically suppresses the final total.
Historical Base Rates & The Compute Injection Forecasters broadly agree that while Q1 2026 saw massive instability and high outage durations due to severe capacity constraints (the “success tax”), July 2026 will benefit from a vastly improved hardware baseline. Anthropic’s massive May/June compute expansion—specifically the 300-megawatt SpaceX Colossus 1 data center integration—is expected to resolve the foundational GPU shortages that caused earlier rolling blackouts.
July 2026 Cross-Currents: Seasonality and Scheduled Risks Forecasters balance several opposing forces unique to July:
Conclusion Overall, the rationales project a stabilized central scenario reflecting Anthropic’s upgraded compute capacity and favorable summer traffic trends, keeping routine outages relatively low. However, all models acknowledge a persistent, right-skewed vulnerability. A single complex deployment bug, an upstream cloud thermal failure, or an unpredicted traffic spike could easily bypass the “status page math” and result in multi-hour systemic blackouts.
Question: How many total hours of outages will Claude’s uptime page show during July 2026? Final Prediction: Probability distribution:
Total Cost: extra_metadata_in_explanation is disabled Time Spent: extra_metadata_in_explanation is disabled LLMs: extra_metadata_in_explanation is disabled Bot Name: extra_metadata_in_explanation is disabled
Forecaster 1: Probability distribution:
Forecaster 2: Probability distribution:
Forecaster 3: Probability distribution:
The research examines the potential total hours of outages for Claude’s uptime page during July 2026, analyzing current status, historical data, and various contextual factors. As of May 2026, Claude’s uptime has fluctuated between 98.67% and 99.87%, with third-party monitoring indicating 58 incidents in the preceding 90 days, including 17 major incidents. Historical data from Q1 and Q2 of 2026 shows a trend of increasing downtime, with significant outages occurring in March and May, leading to an estimated average of around 6.7 hours of downtime per month in Q1. The analysis also highlights the impact of surging user demand and infrastructure strain, alongside ongoing reliability improvements by Anthropic.
Key uncertainties affecting the outage prediction for July 2026 include the effectiveness of reliability enhancements, continued user growth, and the potential for significant unplanned outages. The research suggests a central estimate for total outage hours in July could range from 4 to 8 hours, with the possibility of lower or higher totals depending on various factors, including the occurrence of major incidents.
Sources used in the research include:
As of May 12, 2026, Claude’s official status page (status.claude.com) reports 90-day uptime ranging from 98.67% to 99.87% across different service components (claude.ai, Claude API, Claude Code, etc.) [1]. Third-party monitor Pulsetic has detected 58 incidents in the last 90 days, including 17 major or critical incidents, with a median resolution time of 46 minutes and a 95th percentile resolution time of 3 hours 14 minutes [2].
Q1 2026 (January–March):
Q2 2026 (April–May so far):
| Uptime % | Monthly Downtime (hours) |
|---|---|
| 98.67% | ~9.9 hours |
| 99.0% | ~7.4 hours |
| 99.5% | ~3.7 hours |
| 99.87% | ~1.0 hours |
| 99.9% | ~0.7 hours |
The 98.67%–99.87% range reported across components [1] translates to roughly 1–10 hours of downtime per month, depending on which service is being measured. The question sums all partial and major outages across the entire status page, which would tend toward the higher end of this range.
Surging demand: Claude’s free user numbers increased over 60% since January 2026, and Claude reached #1 in the US Apple App Store AI category [16]. Anthropic’s revenue is reportedly growing tenfold in 2026 [17]. This growth is a primary driver of capacity-related outages.
Mass migration from ChatGPT: Following OpenAI’s Pentagon deal, users flocked to Claude, driving it to top app store charts across multiple countries [17]. This surge has strained infrastructure.
Reliability investments: Anthropic’s reliability engineering team is working on backend improvements and plans to share updates later in 2026 [10]. Improvements in rate-limiting and control-plane redundancy are planned [9].
Outage characteristics: Most outages are 15–30 minutes; scheduled maintenance is typically 1–2 hours; major incidents requiring extensive fixes can last several hours but are described as “rare” [5][8]. However, the 18-hour May 6 outage and the ~10-hour March 2 outage show that tail events can be substantial.
Typical outage pattern: Unplanned outages “often resolve within 15-30 minutes but sometimes last several hours” [5]. The distribution is heavily right-skewed—most incidents are short, but occasional multi-hour events drive the monthly total.
No specific prediction market was found for this exact question (total Claude outage hours in July 2026). General AI milestone markets exist on Polymarket/Kalshi with ~$25M volume but are judged “low-quality” [13]. Metaculus may have related questions but none specifically targeting this metric were identified. The absence of a liquid market means there’s no market-implied probability to anchor on.
| Period | Estimated Monthly Outage Hours | Source |
|---|---|---|
| Q1 2026 average | ~6.7 hrs/month | [10] |
| Worst month (March 2026) | ~15–20 hrs (est.) | [6][15][10] |
| Lighter months | ~2–5 hrs | Inferred from [1][2][12] |
| Status page 90-day range | ~1–10 hrs/month (component-dependent) | [1] |
Based on the data, a reasonable central estimate for July 2026 total outage hours would be in the 4–8 hour range, anchored by the Q1 2026 average of ~6.7 hours/month. However, the distribution is significantly right-skewed: there’s a meaningful probability of a very low month (1–3 hours if reliability improvements succeed and no major incidents occur) and a non-trivial tail risk of 15+ hours if a major capacity crisis or infrastructure failure occurs. The trend of rapid user growth creating capacity pressure [16][17] competing against Anthropic’s reliability investments [9][10] is the key dynamic to monitor in the lead-up to July.
(a) Time remaining: Approximately 1.5 months until July 2026 begins, and 2.5 months until the full resolution (end of July 2026).
(b) Outside view - Reference class and base rates:
(c) Inside view - Key evidence updating from base rates:
(d) Outcome if nothing changed: ~6.7 hours (Q1 average)
(e) Outcome if current trend continued: The trend shows rising user demand competing with infrastructure scaling. If both continue, expect 7-10 hours with elevated tail risk.
(f) Expert/market expectations: No specific prediction market found for this metric. Research did not identify expert forecasts.
(g) Low outcome scenario: Anthropic’s reliability improvements fully deploy by July; demand growth stabilizes; no major incidents; improved redundancy prevents cascading failures. Result: 1-2 hours total.
(h) High outcome scenario: Multiple major infrastructure failures similar to the 18-hour May 6 event; continued user surge overwhelms capacity; authentication system failures; a new feature rollout causes extended instability. Result: 30+ hours total.
Starting from the Q1 2026 base rate of ~6.7 hours/month, I make the following adjustments:
Slight upward adjustment (+0.5-1 hr): Continued rapid user growth (60%+ since January, #1 in app stores) suggests capacity pressure will persist. The May 6 (~18 hr) and March 2 (~10 hr) outages demonstrate that multi-hour events are not rare.
Slight downward adjustment (-0.5 hr): Anthropic has 2+ months to implement planned reliability improvements. Their public commitment to updates later in 2026 suggests active remediation work.
Net assessment: These roughly cancel, leaving the median near 6-7 hours, perhaps slightly higher given growth momentum.
Distribution shape: Strongly right-skewed. Most incidents resolve in 15-30 minutes (per research), but occasional multi-hour events dominate monthly totals. There’s meaningful probability mass in the 15-25 hour range (bad month with a major incident) and non-trivial tail risk at 40+ hours (multiple major incidents).
Lower bound considerations: True zero outages over a full month is extremely unlikely given recent incident frequency (58 incidents in 90 days). Even the best months appear to have some partial outages.
“ Percentile 0.1: 0.3 Percentile 1: 0.8 Percentile 5: 1.8 Percentile 10: 2.8 Percentile 20: 4.0 Percentile 30: 5.0 Percentile 40: 6.0 Percentile 50: 7.0 Percentile 60: 8.5 Percentile 70: 10.5 Percentile 80: 13.5 Percentile 90: 19.0 Percentile 95: 28.0 Percentile 99: 48.0 Percentile 99.9: 78.0 “
The critic makes several compelling points that warrant adjustment:
May 2026 recency problem: This is my most significant error. With ~20+ hours of outages in just the first 9 days of May, my median of 6.8 (essentially unchanged from Q1’s 6.7) was inconsistent with observable trend data. The critic correctly identifies this as recency underweighting.
Internal inconsistency: Fair catch - I stated “small upward bias to ~7 hours” but delivered 6.8. This undermines credibility of my reasoning.
Reliability improvement optimism: Two months for meaningful infrastructure changes at a company with 10x revenue growth is indeed aggressive. Enterprise reliability engineering typically operates on longer timelines.
Right tail underweighting: With both an 18-hour (May 6) and ~10-hour (March 2) incident in the same quarter, my P90 of 23 hours assumes only one such event. The demonstrated possibility of multiple major incidents deserves more probability mass.
May 6 incident specificity: The 18-hour outage was related to GitHub IP restrictions for Claude Code - a configuration issue rather than pure capacity failure. This provides some reason not to fully extrapolate May’s first 9 days.
Status page measurement: The resolution uses the official status page, which (as the critic notes) tends to underreport. This actually suggests official resolution values may be somewhat lower than true outage time.
Regime shift consideration: The April-May pattern may represent a fundamentally different operating environment than Q1. The ChatGPT-to-Claude migration created a step-change in demand that Q1 data doesn’t capture. I should weight recent months more heavily.
The critic’s distribution is reasonable, but I’ll settle slightly below their median (7.8 vs 7.5) because I still see the May 6 GitHub-specific incident as partially idiosyncratic, and status pages systematically undercount real outages which works toward lower resolution values.
Updated prediction:
Percentile 0.1: 0.15 Percentile 1: 0.6 Percentile 5: 1.8 Percentile 10: 2.7 Percentile 20: 4.0 Percentile 30: 5.2 Percentile 40: 6.4 Percentile 50: 7.8 Percentile 60: 9.5 Percentile 70: 12.5 Percentile 80: 16.5 Percentile 90: 26 Percentile 95: 38 Percentile 99: 62 Percentile 99.9: 90
The critic raises several compelling points that deserve acknowledgment:
1. May 2026 trajectory is seriously concerning. This is the strongest criticism. The first 12 days of May have already seen ~20+ hours of outages, which would make it the worst month on record. My original forecast implicitly assumed reliability improvements would succeed in 6-8 weeks—an assumption with meaningful execution risk.
2. Left tail was too optimistic. With 58 incidents detected over 90 days (roughly 20/month) and ongoing growth pressures, achieving <1.2 hours in July would require near-perfect operations. The floor should be higher.
3. “Reliability improvements” narrative is speculative. Anthropic has known about these issues since Q1, yet May appears worse than previous months. Good intentions don’t equal executed improvements.
1. Mean reversion is still likely. While May looks terrible, extreme months typically trigger aggressive responses. The 18-hour May 6 incident was specifically related to GitHub IP restrictions—a discrete technical issue now identified and presumably addressed.
2. Business incentives are powerful. With Claude at #1 in the App Store and revenue growing tenfold, outages directly hurt Anthropic’s bottom line. This creates strong pressure for emergency reliability investments.
3. Two months provides meaningful time. From mid-May to July 1 is 6-7 weeks—sufficient for targeted infrastructure improvements if prioritized.
The escalating pattern (Q1 → April → May) is more informative than simple averages. However, the May 6 incident appears to be a specific technical failure rather than evidence of systemic degradation. The question is whether June will show improvement or continued deterioration—that signal will significantly inform July outcomes.
I accept the following adjustments:
I’m not going as far as the critic’s 6.8 median because I believe some improvement response is likely after May’s poor performance, and the May 6 incident appears to be a discrete technical issue rather than systemic collapse.
Updated prediction:
Percentile 0.1: 0.15 Percentile 1: 0.45 Percentile 5: 1.4 Percentile 10: 2.2 Percentile 20: 3.2 Percentile 30: 4.2 Percentile 40: 5.2 Percentile 50: 6.5 Percentile 60: 7.8 Percentile 70: 10.0 Percentile 80: 14.0 Percentile 90: 21.0 Percentile 95: 31.0 Percentile 99: 52.0 Percentile 99.9: 82.0
Agent Forecast (numeric, confidence: medium)
Base Rate: Per-service uptime as of May 2026: claude.ai 99.51%, console.anthropic.com ~99.21%, api.anthropic.com ~99.3% (30-day rolling). Each implies ~3-6h monthly downtime per service. With 4-6 services summed and many incidents affecting multiple services simultaneously, recent months totalled ~15-30h aggregate; July expected ~7-15h with continued (but diminishing) improvement.
Initial Reasoning:
Key Uncertainties:
Evidence Sources (11):
Grounding Facts (passed to reviewers):
Draft: 2-5: 31.0%, 5-10: 26.0%, 10-25: 16.0%, 1-2: 12.0%, 25-100: 6.0%
Reviewer Panel:
Reviewer (reasoning)
The forecast’s weakest link is the assumption that compute-capacity increases will directly yield a 40% month-over-month reduction in downtime, overlooking software and networking failure modes that aren’t capacity-limited. It also fails to account for the fact that Claude’s status page reports per-service outages (currently six services), which would multiply total reported hours. Finally, it leans heavily on a simple exponential improvement trend without modeling base rates for software reliability improvements or residual human error.
Objections:
Reviewer (calibration)
The forecast significantly underestimates the total outage hours by focusing primarily on a ‘single service’ estimate, despite the resolution criteria clearly stating that outages will be summed across all services listed on Claude’s public status page. While compute expansion is a positive factor, assuming full deployment and stable integration of massive infrastructure by July, coupled with the elimination of other outage causes, is overly optimistic. The current probability distribution does not adequately reflect the higher totals likely from aggregating multiple service downtimes.
Objections:
Reviewer (fact-checker)
7 unsupported claim(s). Verdict: minor_issues
Unsupported claims:
Adjustment Rationale:
Shifted significant probability mass from the 2-5h bin upward into 5-10h (0.26→0.32) and 10-25h (0.16→0.27), and increased 25-100h (0.06→0.12), because both the calibration and reasoning reviewers correctly identified that the resolution methodology sums outage durations across ALL services on status.claude.com/uptime, not just claude.ai. Verification confirmed the page lists at least 4-6 distinct components (claude.ai, Claude Console/platform.claude.com, Claude API/api.anthropic.com, Claude Code, plus model-specific entries), each with separate daily uptime bars. Per-service May rates are ~3-5h each (claude.ai 99.51%, Console 99.21%, API 99.3%), and many major incidents (e.g., April 28’s 1h34m event) affect 3+ services simultaneously, multiplying summed duration. Even with continued compute-driven improvements from SpaceX Colossus and Amazon Trainium2 capacity, plausible July per-service downtime of ~1-4h across 4-6 services yields a central estimate of ~7-15h. Also incorporated reviewer feedback about diminishing returns on the improvement trend and software/network failures that aren’t capacity-limited.
forecast_sdk | 510.9s | research $0.6523 + reviewers $0.0081 + reconcile $0.3713 = $1.0318
Extracted Percentile Values: {0.1: 1.02, 1.0: 1.25, 5.0: 2.0, 10.0: 2.9, 15.0: 3.7, 20.0: 4.5, 25.0: 5.2, 30.0: 5.9, 35.0: 6.6, 40.0: 7.2, 45.0: 7.8, 46.0: 7.95, 47.0: 8.1, 48.0: 8.25, 49.0: 8.4, 50.0: 8.6, 51.0: 8.8, 52.0: 9.0, 53.0: 9.2, 54.0: 9.45, 55.0: 9.7, 60.0: 10.6, 65.0: 11.7, 70.0: 13.1, 75.0: 15.0, 80.0: 17.8, 85.0: 21.8, 90.0: 27.5, 95.0: 39.0, 99.0: 82.0, 99.9: 132.0}
Model’s Answer: Step one is anchoring on the official status data, because the resolution source is the Claude uptime page itself. The strongest concrete evidence is the recent monthly uptime summary: March 2026 at 98.21 percent implies about 13.3 outage hours, and April 2026 at 98.86 percent implies about 8.2 outage hours. The 90-day figure of 98.67 percent is also consistent with a recent regime of roughly high-single-digit to low-teens outage hours per month rather than near-zero downtime.
Step two is adjusting for what the incident feed says about shape, not just level. The status page and third-party trackers show many incidents, mostly partial and mostly short, with occasional larger events. That pattern matters because this market resolves on total hours, so a month can land around 6 to 12 hours through lots of small events, while still having a meaningful right tail if one bad multi-hour or multi-day incident occurs. I weight the official uptime page most, the official incident log next, and third-party reports mainly as confirmation that outages are frequent but usually not catastrophic.
Step three is deciding whether July should be better or worse than the recent base rate. There are two offsetting forces. On one side, Anthropic appears to be improving from March toward May, which pulls the central estimate down somewhat. On the other side, commentary and outage reporting suggest ongoing scaling stress and frequent degradations, which keeps me from projecting a clean, low-downtime month. With only about seven weeks until July starts, the base case should still look fairly similar to recent months unless something materially changes.
The most important assumptions are these. First, that July reliability is broadly similar to the March through May regime rather than undergoing a step-change; I think there is about a 35 percent chance this assumption is materially wrong. Second, that July does not contain a major launch, demand spike, or infrastructure regression that creates a long outage cluster; about a 20 percent chance this is wrong. Third, that the monthly uptime percentages are a good proxy for the hover-card sum used in resolution; about a 15 percent chance this is wrong enough to matter. Those failure modes mostly widen the right tail.
A low outcome would come from a quiet month with only scattered short partial outages, likely in the 2 to 5 hour range overall. I put that general low-outcome story at roughly one chance in five. A high outcome would come from one major incident or several medium incidents stacking up, pushing totals into the 20 to 40 plus hour range; I put that broad high-outcome story at roughly one chance in six, with truly extreme outcomes above 100 hours still very unlikely but not impossible. My median is therefore just under 9 hours, with a wide upper tail.
Percentile .1: 1.02 Percentile 1: 1.25 Percentile 5: 2.00 Percentile 10: 2.90 Percentile 15: 3.70 Percentile 20: 4.50 Percentile 25: 5.20 Percentile 30: 5.90 Percentile 35: 6.60 Percentile 40: 7.20 Percentile 45: 7.80 Percentile 46: 7.95 Percentile 47: 8.10 Percentile 48: 8.25 Percentile 49: 8.40 Percentile 50: 8.60 Percentile 51: 8.80 Percentile 52: 9.00 Percentile 53: 9.20 Percentile 54: 9.45 Percentile 55: 9.70 Percentile 60: 10.60 Percentile 65: 11.70 Percentile 70: 13.10 Percentile 75: 15.00 Percentile 80: 17.80 Percentile 85: 21.80 Percentile 90: 27.50 Percentile 95: 39.00 Percentile 99: 82.00 Percentile 99.9: 132.00
Forecast: median = 5.7316 hours
Overall, while improvements are anticipated due to new infrastructure, the combination of high demand and potential integration issues creates uncertainty around the final outage totals for July 2026.
Forecast (percentiles, aggregated):
Per-model forecasts:
Rationale: Summary Recent historical data from Claude’s status page indicates a steady improvement in platform reliability. Monthly downtime has decreased from approximately 13.3 hours in March 2026 (98.21% uptime), to roughly 8.2 hours in April (98.85% uptime), and is pacing toward 3.6 hours for May (99.51% uptime). This trend suggests Anthropic is actively and effectively addressing the capacity issues that previously caused elevated outage rates. However, managing rapidly scaling AI infrastructure remains inherently volatile. The median estimate of 4.6 hours acknowledges this stabilization while building in a slight buffer above the May trajectory to account for the persistent risk of minor disruptions. Furthermore, the strict resolution criteria sum only the durations of “Major outage” and “Partial outage” states. Because “Degraded performance” periods do not contribute to this sum, the final resolved value may be noticeably lower than the downtime implied by the raw overall uptime percentage. The distribution remains significantly right-skewed, leaving room for severe regression scenarios akin to those observed in early 2026.
Strongest Arguments for Higher Values
Strongest Arguments for Lower Values
Key Uncertainties
Atlassian’s Statuspage documentation says the historical uptime view is driven by minutes spent in partial-outage and major-outage states, and that users inspect uptime on a per-component basis. Claude’s public status page currently shows multiple separate components with their own 90-day uptime figures and links to the historical uptime view. That creates real interpretation risk for this market question: the prompt talks about “the uptime page” as if it were singular, but the underlying product is component-specific. A cached component-specific uptime result plus an independent open-source monitor mapping that component ID to “Claude API” makes me think the default/canonical interpretation is probably the Claude API component, but not with full confidence. (support.atlassian.com)
On May 12, 2026, Claude’s official status page showed 90-day uptime of 99.01% for Claude API, 98.67% for claude.ai, and 99.17% for Claude Code. Over 90 days (2,160 hours), those percentages imply about 21.4 hours of API downtime, 28.7 hours of claude.ai downtime, and 17.9 hours of Claude Code downtime. That is roughly 7.1 hours per 30-day month for API alone, or about 22.7 hours per 30-day month if a resolver effectively aggregates those three main services instead. (status.claude.com)
The recent incident flow also looks clustered rather than smooth. Claude’s official history shows no incidents on May 10–12, 2026, but repeated incidents on May 4, May 6, May 7, May 8, and May 9, 2026, with multiple short-to-medium events on some of those days. That clustering matters: monthly outage totals for services like this are usually overdispersed, with many ordinary days and occasional bad streaks. (status.claude.com)
As a secondary volatility check, The Nines says its Claude history mirrors the provider’s published daily uptime view, and its public repository stores day-level outage-minute rollups and per-component details sourced from public status data. In that mirror, aggregate Claude outage-minutes were 2,613 in February 2026, 6,695 in March 2026, and 1,734 in the sampled part of April 2026, which is a useful reminder that bad months can be far worse than the recent 90-day average. I do not treat that mirror as the resolution source, but I do use it to widen the right tail. (thenines.online)
My final forecast is therefore a mixture of scenarios: 5% probability of a clean 0-hour month; 70% weight on a default-component/API interpretation centered around roughly 7 hours; and 25% weight on a broader page-level interpretation centered around roughly 21–22 hours. That yields a mean forecast of about 10.5 hours for July 2026, with most probability mass in the mid-single-digits to mid-teens, but with a meaningful tail into 30+ hours if outages cluster again. If the resolver later clarified that only the default Claude API component counts, I would move the distribution down; if the resolver clarified that multiple components are effectively aggregated, I would move it up. (support.atlassian.com)
I first had to interpret the target. Atlassian’s documentation says the
/uptimepage is per-component and users choose which component to inspect. The prompt does not specify a component. Claude’s official components API lists the showcased components in order and putsclaude.aifirst, so I assume resolution uses the defaultclaude.aiview shown when opening/uptime. If the resolver instead selects another component or aggregates multiple components, the true value could differ materially; that ambiguity is one reason I keep a fairly wide distribution. (support.atlassian.com)My main anchor is the official 90-day uptime figure. As of May 12, 2026, Claude’s status page shows
claude.aiat 98.67% uptime over the past 90 days. Atlassian explains that this uptime percentage is based on major-outage minutes plus 0.3 times partial-outage minutes, while degraded performance and maintenance do not count. Converting 98.67% over 90 days implies about 28.728 weighted outage hours in 90 days, or about 9.895 weighted hours in a 31-day month if the recent pace continues. (status.claude.com)Because the question resolves on raw outage hours, with major and partial counted equally, I then translate weighted downtime into raw downtime. Recent official incidents show why raw hours are higher than the status-page uptime formula. On April 15,
claude.aiwent major outage at 14:55 UTC, downgraded to degraded at 15:03, returned to major at 15:40, shifted to partial at 16:29, and returned to operational at 17:42; that is 130 raw outage minutes but only 78.9 weighted minutes under Atlassian’s formula. On April 23, theMCP apps unavailable on Claude.aiincident was a 16-minute partial outage, which counts as 16 raw minutes but only 4.8 weighted minutes. On April 28,Claude.ai unavailable and elevated errors on the APIputclaude.aiinto major outage from 17:41 to 18:59 UTC, so raw and weighted minutes were both 78. These examples suggest a raw-to-weighted multiplier centered around roughly 1.45, but with a wide plausible range depending on how partial-heavy the month is. Applying that multiplier to the 9.895 weighted-hour baseline gives about 14.35 raw hours for a July-like month. (status.claude.com)I do not see strong evidence that reliability is clearly improving yet. An official snapshot from about three weeks earlier showed
claude.aiat 98.79% 90-day uptime, versus 98.67% now, so the rolling picture worsened slightly rather than improved. The public incident history and secondary tracking also show a dense cluster of late-April and early-May incidents, including several majorclaude.ai-affecting events. That said, outages are lumpy, and one unusually quiet or unusually bad month can differ a lot from the recent average, so I widened the upper tail rather than just projecting the recent mean mechanically. (status.claude.com)My final distribution therefore has a median around 13 hours and a mean around 15 hours, with a small but real chance of a near-clean month and a long right tail for another April-style cluster or a single multi-hour incident. In words: the most likely outcome is low-teens outage hours, roughly 8 to 22 hours is my core range, but I leave meaningful probability above 30 hours and a thin tail beyond 50 hours. (status.claude.com)
Atlassian’s documentation says the /uptime page is a per-component uptime view: users select a component and see daily downtime, and only major outage and partial outage states affect that uptime history. The same documentation also says degraded performance and maintenance do not count for uptime-history calculations, and that partial outages are discounted to 30% of major outages when Statuspage computes uptime percentages. That matters here because your resolution rule is different: it sums raw Major outage and Partial outage durations equally, so the public uptime percentages are informative but not directly equal to the resolving value. (support.atlassian.com)
On May 12, 2026, Claude’s main status page showed 90-day uptime figures of 98.67% for claude.ai, 99.11% for Claude Console, 99.01% for Claude API, 99.17% for Claude Code, 99.40% for Claude Cowork, and 99.87% for Claude for Government. Converting those percentages into Statuspage’s weighted downtime over a 90-day window gives about 28.728, 19.224, 21.384, 17.928, 12.96, and 2.808 hours respectively. Earlier snapshots visible in search results on April 9, 2026 and April 17, 2026 were in a similar band rather than showing a clear reliability step-change, so I do not assume July 2026 will suddenly be much cleaner than the recent baseline. (status.claude.com)
Recent incident details show that countable downtime has included both major-outage and partial-outage states. For example, on April 30, 2026, the incident claude.ai and API unavailable moved all major components into major_outage from 01:20 UTC until resolution at 01:51 UTC, about 31 minutes. On April 25, 2026, Elevated error rates on Claude Opus 4.7 placed claude.ai, Console, API, Claude Code, and Claude Cowork into partial_outage, with the resolved note saying impact occurred from 01:24 to 01:59 UTC, or 35 minutes. On April 15, 2026, a critical incident escalated several components into major_outage and later moved claude.ai and Console into partial_outage before final resolution. Those examples imply that raw outage hours for this market should usually sit above the Statuspage-weighted downtime figures, but not wildly above them. (status.claude.com)
The biggest residual uncertainty is interpretive: Atlassian says /uptime is per-component, but the resolution text does not name a component. Because of that ambiguity, I widened the distribution to cover a default-view interpretation as well as somewhat lower- or higher-downtime component choices. I then centered the forecast in the low-teens hours for July 2026: higher than a naive monthly average of the weighted uptime figures because partial outages count fully for resolution, but not so high as to assume another extreme multi-hour failure month by default. I also kept a meaningful right tail because Claude’s recent incident history from late March through early May 2026 shows repeated clusters of authentication, model, and availability incidents rather than isolated one-offs. (support.atlassian.com)
My main interpretive assumption is that this market will resolve against the default/public Claude uptime component view, which appears to be component-based rather than a single pagewide rollup. Atlassian’s own documentation says the
/uptimepage is a per-component historical uptime view, and search results expose a Claude uptime URL at/uptime/k8w3r06qmzrp; Claude’s public components endpoint mapsk8w3r06qmzrpto “Claude API (api.anthropic.com).” If the resolver instead chooses a different component, the distribution would shift by a few hours, but not by an order of magnitude. (support.atlassian.com)The most important mechanical fact is how Atlassian Statuspage computes uptime history. Atlassian says uptime history is driven only by time spent in
major_outageandpartial_outage;degraded_performanceand maintenance do not count. It also says partial outages are discounted to 30% of major outages in the displayed uptime percentage, and page owners can manually edit historical uptime/downtime. So the official uptime page is the right anchor for this forecast, but incident titles alone are an imperfect proxy for the exact resolving number. (support.atlassian.com)As of May 12, 2026, Claude’s public status page shows 90-day uptimes of 98.67% for claude.ai, 99.11% for the console, 99.01% for Claude API, 99.17% for Claude Code, 99.39% for Claude Cowork, and 99.86% for Claude for Government. Under my API-view assumption, 99.01% over 90 days implies about 21.384 weighted outage-hours over 2,160 hours, or about 7.128 weighted outage-hours per 30-day month. That is a useful base rate, but because partial outages are discounted in the percentage formula, the exact resolver-facing “major + partial hours” total should generally be higher than that weighted figure. (status.claude.com)
Recent official incident history argues against a near-zero July. Claude’s status history shows many API-affecting incidents in late March through early May 2026, including elevated timeouts from 17:45 UTC on March 31 through 05:52 UTC on April 1, an April 6 incident from 15:00–16:30 UTC, an April 8 Sonnet 4.6 incident from 06:23–09:33 UTC plus another April 8 authentication incident from 17:25–17:44 UTC, an April 15 issue that briefly moved the API into
major_outagebefore recovery, and an April 28 incident where API impact ran from 17:34–18:52 UTC. That pattern looks like a fairly high-incident, fat-tailed service rather than one that usually posts zero outage-hours for a full month. (status.claude.com)Putting that together, I center July 2026 near 13 total outage-hours on the uptime page. The logic is: start from roughly 7.1 weighted hours/month from the official 90-day API uptime, then uplift because the resolver counts partial outage minutes fully while Atlassian’s percentage discounts them to 30%, and because recent Claude incidents are often “elevated errors” style events more consistent with partial outages than with long pure major outages. I therefore put only modest mass on very low totals, most mass in roughly the 3-to-30 hour region, and a small but real right tail above 40 hours if July contains one sustained multi-hour incident or a cluster of shorter ones. (status.claude.com)
As of May 12, 2026, I am treating this as a forecast of what the public Statuspage UI will display, not necessarily true underlying service availability. Atlassian’s uptime showcase only uses major outage and partial outage states to drive historical uptime; degraded performance and maintenance do not count. For the displayed uptime percentage, partial outage is discounted to 30% of major outage, and page owners can also edit historical uptime/downtime after the fact. Those mechanics matter a lot here because this market resolves on raw outage hours shown on the page, not on the weighted uptime percentage. (support.atlassian.com)
There is also an interpretation ambiguity in the market wording. Atlassian documents uptime history as a per-component feature, while Claude’s public status page currently exposes multiple components with uptime histories. Separately, Statuspage computes an overall top-level page status by blending component states; on pages with 2 or more components, any component in major outage yields a page top status of Partial System Outage, while any component in partial outage yields Minor Service Outage. Because the question points to the generic /uptime URL rather than a component-specific uptime URL, I think it is safer to widen the forecast rather than overfit to any one single component. (support.atlassian.com)
The current official status page already shows a fairly weak recent reliability baseline. In the latest official crawl, 90-day uptime is listed as 98.67% for claude.ai, 99.11% for Claude Console, 99.01% for the Claude API, 99.17% for Claude Code, 99.39% for Claude Cowork, and 99.86% for Claude for Government. Converting those percentages into Atlassian-weighted downtime implies roughly 28.7, 19.2, 21.4, 17.9, 13.2, and 3.0 weighted downtime hours over 90 days, respectively; across the five non-government surfaces that averages about 20.1 weighted hours per 90 days, or about 6.7 weighted hours per month before translating into this market’s raw-hours definition. (status.claude.com)
Because this market counts partial outage minutes fully, while Statuspage’s percentage formula only counts them at 30%, the raw outage-hour total should generally be materially higher than the weighted downtime implied by the official uptime percentages. The April 15 official incident feed is a good example: the incident moved components through major outage, then degraded, then back to major, then partial before resolution. In a pattern like that, raw major-plus-partial hours are notably larger than the weighted downtime that Atlassian would use for the displayed percentage. (support.atlassian.com)
Recent official history also shows that Claude is in a genuinely noisy incident regime, not a one-off bad day. The official page lists incidents across Apr 27, Apr 28, Apr 29, Apr 30, and May 4, 6, 7, 8, and 9, including a widespread Apr 28 claude.ai/API incident and multiple early-May incidents across models and surfaces. The official API documentation also notes that the public incidents endpoint returns only the 50 most recent incidents, so the cleanest official calibration is recent-history extrapolation plus current 90-day uptime rather than a long multi-year sample. (status.claude.com)
For structural base rates, I also used the 2025 ICPE paper on public LLM outages. Its abstract reports that Claude failures occurred more frequently than ChatGPT failures, and that Anthropic/OpenAI failures showed weekly and monthly periodicity. That makes me reluctant to assume that the spring 2026 outage cluster is pure noise that will disappear by July. (arxiv.org)
My synthesis is: a stabilized-but-still-imperfect July points to something like low-teens raw outage hours; a continuation of the current spring 2026 incident tempo makes totals in the 20s or 30s quite plausible; and a clean month with zero counted partial/major outage hours is possible but unlikely. I therefore centered the distribution around a median of roughly 12 to 13 hours, with a mean around 18 hours and a long right tail. I left a small but real chance above 100 hours because the recent regime includes clustered incidents, the market wording is somewhat ambiguous about page-vs-component interpretation, and Statuspage history can be edited after incidents. (support.atlassian.com)