DEV Community: Prismix

Which AI APIs go down most? Data from 6 weeks monitoring 77 services

Prismix — Fri, 17 Jul 2026 10:56:37 +0000

Every developer who has shipped an AI-powered feature knows the moment. Your logs light up with 500s or timeouts, your users are reporting failures, and your first instinct is to open a new tab and type "is OpenAI down." The status page loads green. You stare at it for a second. Then you go check Twitter.

That gap between "something is clearly wrong" and "the status page admits something is wrong" is where real incidents live — and it's what motivated us to build Prismix.

How we collect the data

For the past six weeks, Prismix has been polling the official status pages and running direct API health probes against 77 AI services every five minutes. That includes the obvious ones — OpenAI, Anthropic, Gemini, Mistral, Groq, Perplexity, GitHub Copilot, DeepSeek — plus the growing wave of image, audio, and video generation services: ElevenLabs, Runway, Replicate, Stability AI, and dozens more.

Each probe records response latency, HTTP status codes, and whether the official status page matches what we're actually seeing. The result is a dataset of thousands of polling cycles per service, spanning incidents both small and significant.

Here's what we found.

OpenAI leads in incident volume — Anthropic leads in resolution speed

By raw incident count, OpenAI has more status events than any other provider in our dataset. That's not a knock on their reliability — it's a function of surface area. OpenAI runs the most products, has the most API surface, and serves the most traffic. More moving parts means more opportunities for something to report degraded.

What's interesting is the contrast with Anthropic. Anthropic logs fewer incidents by count, but the pattern that stands out is resolution time. When Anthropic posts an "investigating" status, it tends to move to "resolved" faster than the category average. Whether that reflects a smaller blast radius, tighter incident runbooks, or simply fewer services in play, the outcome is the same: shorter mean time to resolution.

The "investigating" phase is where developers panic — but it usually ends fast

When a status page flips from green to "investigating," developers go into triage mode. Do we fall back to a different model? Do we queue requests and wait? Do we page someone?

The data suggests: in more than 80% of cases, "investigating" → "resolved" completes within two hours. Most incidents are shorter than that. Catastrophic multi-hour outages exist — we've recorded several — but they're the exception, not the pattern.

The practical implication: a retry loop with exponential backoff covering the first 30–60 minutes handles the majority of incidents transparently to end users. Full circuit-breaker logic and cross-provider routing matters for the tail, not the median.

Status pages lag reality by 10–20 minutes — consistently

This is the finding that surprised us least but that developers most need to hear explicitly: official status pages are systematically late.

We've recorded dozens of incidents where our API probes showed elevated error rates, degraded latency, or 429 storms well before the corresponding status page acknowledged anything. The typical lag is 10–20 minutes. In some cases it's longer.

"Silent degradation" — where an API returns errors or slows down significantly before any public acknowledgment — is the default incident pattern, not an edge case. If your alerting depends solely on status page webhooks, you have a 10–20 minute blind spot by design.

The most stable services might surprise you

The services with the fewest incidents in our dataset are Groq, Mistral, and Cerebras. All three are newer entrants, run narrower API surfaces, and focus almost exclusively on inference rather than operating multi-product ecosystems. Fewer integrations, fewer failure domains.

This isn't a permanent characteristic — as these platforms grow, complexity tends to follow — but right now, if raw uptime is the top priority for a workload, the smaller inference providers punch above their weight.

OpenAI and Anthropic incidents don't correlate

One of the more useful findings for system design: OpenAI incident windows do not meaningfully overlap with Anthropic incident windows. Their infrastructure, their scaling events, and their failure modes are largely independent.

This is the empirical case for routing across providers. If you have a fallback path from an OpenAI call to an equivalent Anthropic call, the two failure probabilities multiply rather than add. The redundancy is real, not theoretical.

What this means for how you build

A few practical conclusions from six weeks of data:

Design for the degraded state. Most AI API failures are partial — elevated latency, elevated error rates, not a total blackout. Streaming with timeouts, graceful fallbacks to cached responses, and user-facing "AI is slow right now" messaging all perform better than assuming the API is binary up or down.

Don't use the status page as your real-time signal. Use it for incident communication and post-mortems. For real-time detection, you need your own probes.

Route across independent failure domains. The OpenAI/Anthropic correlation data supports this directly. Treating providers as interchangeable based purely on model capability misses the reliability dimension.

Add status checks to your own monitoring

Prismix exposes a public REST endpoint — no API key required:

GET https://prismix.dev/api/v1/statuses

It returns current status for all 77 services in a single JSON response. Drop it into your existing health check pipeline, your Grafana dashboard, or your on-call runbook.

The dashboard itself is at prismix.dev — free, no account required. If you're building on top of AI APIs and you're not watching the upstream services you depend on, this is the lowest-effort way to start.

We'll keep publishing findings as the dataset grows. Six weeks is a start; six months will be more interesting.

We built a free MCP server so Claude can answer 'Is OpenAI down?' — here's how

Prismix — Tue, 14 Jul 2026 09:11:17 +0000

You're deep in a coding session. Something breaks. The model call returns nothing. Your first instinct is to open a new tab, navigate to the vendor's status page, wait for it to load, and try to figure out if "Degraded Performance" means your specific API call is affected or not.

That context switch costs maybe 90 seconds. It feels longer.

At Prismix we track live status for 77 AI services — OpenAI, Anthropic, Cursor, Mistral, Perplexity, GitHub Copilot, and dozens more — at prismix.dev. We already had the data. The obvious next step was surfacing it where developers actually are: inside their AI assistant.

So we built an MCP server.

The setup takes 30 seconds

Add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "prismix-status": {
      "url": "https://prismix.dev/api/v1/mcp"
    }
  }
}

Restart Claude Desktop. That's it. No API key. No account. No npm package to install or keep updated.

What you can ask Claude now

Once connected, Claude has live access to our status data:

"Is OpenAI down right now?"
"Which AI services are currently having incidents?"
"What's the status of Anthropic's API?"
"Has Cursor been having issues today?"
"Show me all services with degraded performance"
"Is it just me or is GitHub Copilot acting up?"

Claude reads the current status, the active incident description, and the affected components — and answers in plain language without you switching context.

How the MCP endpoint works on Cloudflare Workers

The interesting engineering problem was making MCP work on Cloudflare Workers.

Workers are edge functions — stateless, no persistent connections, maximum execution time measured in seconds. The MCP spec was originally designed with stdio transports and long-lived sessions in mind. Those assumptions don't hold at the edge.

The solution was Streamable HTTP transport — the newer MCP transport that works as a standard POST/GET HTTP exchange. Each request is fully self-contained: client sends a JSON-RPC message, server responds, connection closes.

In Astro, the endpoint handles two methods:

GET — returns the server manifest (name, version, available tools)
POST — receives a tool call, fetches fresh status data from KV, returns the result

export const POST: APIRoute = async ({ request }) => {
  const body = await request.json();
  if (body.method === "tools/list") return json({ tools: TOOL_DEFINITIONS });
  if (body.method === "tools/call") {
    const status = await fetchCurrentStatus(); // reads from Cloudflare KV
    return json(formatToolResponse(body.params.name, status));
  }
};

The edge constraint turned out to be an advantage. Because every request is stateless, there's nothing to go wrong between calls. No session to expire, no WebSocket to drop, no daemon to restart. The one tradeoff: MCP sessions that rely on server-sent state across calls need to re-fetch each time. For status data that's fine — we want fresh data anyway.

What people actually ask about

Something we noticed after launching: through the MCP endpoint, Cursor and GitHub Copilot get queried constantly — roughly on par with OpenAI. On the website it's mainly OpenAI and Anthropic.

That makes sense in retrospect. Cursor and Copilot are editor-native tools. When they break, you're already in your editor. Asking Claude via MCP is the natural move — you're already mid-conversation with it.

The right interface for developer tooling status is wherever the developer already is, not a page they navigate to.

Try it

{
  "mcpServers": {
    "prismix-status": {
      "url": "https://prismix.dev/api/v1/mcp"
    }
  }
}

Full setup guide: prismix.dev/mcp-server

Prismix is a free AI infrastructure status hub tracking 77 services. The dashboard, REST API, and MCP server are all free, no login required.

We built a free status monitor for 77 AI APIs. Here's what 6 weeks of data taught us.

Prismix — Mon, 22 Jun 2026 09:59:03 +0000

Every AI developer has been here: your app is throwing 503s, users are pinging you, and you have 12 browser tabs open — OpenAI status page, Anthropic status page, the GitHub Copilot health page, three different Discord servers — trying to figure out is this me or is it them?

That's the problem we set out to solve. Prismix aggregates status from 77 AI services in one place. Six weeks of running it in production taught us some things that might save you time.

The problem is worse than you think

AI APIs don't fail like traditional infrastructure. They fail in weird, partial ways:

Degraded performance that passes your health checks but makes your product feel broken
Regional outages — OpenAI US-East is down while EU is fine, so half your users are affected
Silent rate-limit cascades — the API returns 429s but their status page says "operational" for another 20 minutes
Incident lag — providers often post status updates 10–30 minutes after engineers are already aware

The official status pages are optimistic by design. They're customer-facing communications tools, not real-time engineering dashboards. There's nothing wrong with this — but it means you need a different mental model for "is this service down?"

What 77 status pages look like in aggregate

When you watch 77 AI services simultaneously, patterns emerge fast.

OpenAI is the most-watched service (and has the most incidents to watch). The pattern is almost always the same: investigating → identified → monitoring → resolved, typically in 45–90 minutes. The investigating phase is where most developers panic — it looks bad but usually resolves without action on your end.

Anthropic runs noticeably clean compared to its API usage growth. Incidents are rarer and shorter. When they do happen, updates arrive faster than most providers.

The long tail is interesting. Services like Replicate, Runway, ElevenLabs, and Suno have incident patterns that don't correlate with OpenAI at all. If you're routing across multiple providers for redundancy, these are genuinely independent failure domains — worth knowing.

The "silent degradation" problem is real. Multiple times we've seen a service show "operational" on its status page while our uptime probe was timing out. This is the main reason Prismix shows a latency sparkline per service — the status page is authoritative for announced incidents, but the probe catches real ones.

What Prismix built (and why it's free)

Prismix pulls from official status pages, aggregates them into a single dashboard, and adds a few things that the individual pages don't have:

Per-service latency probes — 24-hour sparklines showing actual response times, not just announced incidents. This catches the "silent degradation" cases.

Cross-service incident timeline — /incidents shows everything that happened across all 77 services in one scrollable feed. Useful for postmortems ("was anything else degraded when our error rate spiked at 3pm Tuesday?").

Embeddable status badges — put a live "OpenAI: operational" badge in your own app's status page with one line of HTML.

Public REST API — GET /api/v1/statuses returns current status for all 77 services as JSON. No auth, no rate limit for reasonable use, CORS open. Free forever.

RSS feed — /incidents.rss if you want AI incident updates in your feed reader.

It's free because it runs entirely on Cloudflare's free tier (Workers + KV). The Pro tier ($10/mo) adds email and webhook alerts for services you care about, but the core dashboard stays free.

The technical part (because this is dev.to)

The stack is Astro 5 SSR + Cloudflare Workers + KV. We wrote about the performance walls we hit in a previous post — the short version is that 77 parallel KV reads per request is a bad idea and a single pre-aggregated snapshot blob is much better.

One thing that surprised us: KV's free tier gives you 100,000 reads per day but only 1,000 writes. The cron job that refreshes status runs every 5 minutes, so every write is conditional — only write if the content actually changed. That dropped writes from ~8,400/day to ~600/day. Monitoring infrastructure has to be cheap to run, otherwise the incentive to keep it free disappears.

What we don't know yet — and why we're writing this

Six weeks in, Prismix tracks 77 services with a clean incident timeline and growing usage. What we don't have yet is signal on what matters to you.

Some things we're genuinely uncertain about:

Which services are missing? The list is opinionated — mostly LLM APIs, popular AI tools, and infrastructure adjacent to them. We've probably missed something obvious in your stack.
Is the latency probe useful? It tells you "this service is slow right now" but not "slow compared to what" — no historical baseline yet.
What would make you actually use this every day? A Slack bot? A PagerDuty integration? Something in your terminal?

If any of that resonates, drop a comment. Honest feedback shapes what gets built next.

Live at prismix.dev.

Also at Prismix: an MCP server directory with 500+ servers and a curated AI news feed — but the status monitoring is the part we're most curious to hear about.

4 perf walls I hit shipping an AI hub on Cloudflare Workers KV

Prismix — Tue, 19 May 2026 09:02:22 +0000

Status pages don't aggregate. AI news lives in 60 RSS feeds. MCP servers are scattered across awesome-lists.

So I built Prismix - one URL for all three - on Cloudflare Workers + Astro 5. Here's what broke and what fixed it.

Live: prismix.dev

Why this exists

Three daily frustrations:

OpenAI / Anthropic status pages don't aggregate — I had 5 tabs open every morning
AI news lives in 60 different RSS feeds and Twitter accounts
MCP servers are scattered across awesome-lists with no canonical index

Prismix solves all three on one page.

The stack

Layer	Choice	Why
Framework	Astro 5 SSR	Islands architecture, $0 hosting
Hosting	Cloudflare Pages	Free tier covers MVP
Database	Cloudflare Workers KV	No DB to operate
Auth	Self-rolled (email + GitHub)	Saved $25/mo vs Clerk
Payments	Ko-fi	No Stripe overhead
Tests	Vitest + MockKV	1112 tests, runs in 8s

The whole thing costs $0 to run. That constraint forced 4 lessons.

Lesson 1 — KV writes are the rare resource

Cloudflare's free tier gives you 100,000 KV reads/day but only 1,000 writes. I hit the wall at 1pm on day 12.

The fix wasn't fewer writes - it was a diff-or-skip pattern: read the existing value, compare, only write if changed.

async function setIfChanged(kv: KVNamespace, key: string, value: string) {
  const existing = await kv.get(key);
  if (existing === value) return false; // skip
  await kv.put(key, value);
  return true;
}

Cron writes dropped from 8,400/day → 600/day. Reads are 100× more generous - trade them freely.

Lesson 2 - JSON.parse has a cliff at 1 MB

The news index grew to 5,000 items. Each KV read returned a 3.2 MB JSON blob. SSR for /news was taking 330ms just to parse.

The fix was splitting the index into a "first page" slice (250 items, 165 KB) and a meta blob (facet counts, 12 KB). When the user hits /news with no filters or pagination, we only read the slice.

// hot path — 17ms
const firstPage = await kv.get('news:index:latest:firstpage:v1', 'json');
const meta = await kv.get('news:index:latest:meta:v1', 'json');

// cold path (filters, sort, page>1) falls back to full index

Parse time: 330ms → 17ms.

Lesson 3 — CF Workers subrequest concurrency is per-request

This one bit me hardest. /mcp was rendering in 5.5s. Server-Timing showed 4.31s spent on KV reads.

I assumed 60 parallel kv.get() calls would run in parallel. They don't — Workers caps concurrent subrequests at ~6, so the rest queue.

The fix: a denormalised snapshot blob updated by cron once a day.

// Before: 60 parallel reads, serialised by concurrency limit → 4.31s
const likes = await Promise.all(slugs.map(s => kv.get(`mcp:likes:${s}`)));

// After: 1 blob read → 30ms
const snapshot = await kv.get('mcp:bulk-engagement:v1', 'json');

Total /mcp SSR time: 5460ms → 380ms.

Lesson 4 — Even fast SSR feels broken without instant feedback

After fixing perf, the site loaded in 200-400ms. Users still complained it was slow.

The problem: the browser doesn't repaint the address bar until the new HTML arrives. For 200ms the user sees nothing — they click again, thinking the button didn't register.

Two fixes:

Pointerdown progress bar — render a 2px green bar at the top of the screen on pointerdown, before the navigation even fires.
Astro tap prefetch — start fetching the next page on pointerdown, finish during the click delay.

document.addEventListener('pointerdown', (e) => {
  const link = e.target.closest('a[href]');
  if (link) showProgressBar();
});

Perceived load time dropped from "slow" to "instant" without a single SSR optimisation.

What didn't work

Algolia for MCP search — overkill; switched to in-memory tokenised index
Stripe — Ko-fi's webhook + idempotency was 1 day vs Stripe's week
Clerk — self-rolled OTP + GitHub OAuth was 3 days, $0/mo
GitHub Actions schedule: — drifts by minutes, silently skips. Moved cron to cron-job.org

What's next

Per-service alert thresholds (Pro feature)
AI news instant-notify via webhook (Discord / Slack)
Public read API + SDK

If you've shipped on Cloudflare Workers and hit different walls, I'd love to hear what broke for you. Comments open.

→ prismix.dev