Blog / Developer tools

How to Build a Status Page for an AI API Service

2026-10-25cdnping editors10 min read

The hard part of building a status page is not choosing a tool. It is deciding four things up front: which components to list, who decides each component's status, what each level means, and what every incident update should say. For an AI API service, split components into "access gateway + model groups + console." Let automated probes and real-request statistics set the status, and leave people to confirm it and write the explanation. This article follows that order and ends with a pre-launch checklist.

As reference points, we use cdnping's own API status page and AGI Plan status page. AGI Plan is a commercial partner of cdnping, so we know both the approach and the shortcomings of these two pages well.

#What questions does a status page need to answer?

When users open a status page, they usually want to know three things:

1. Is the problem I'm seeing on your side?
2. If so, which part is affected, do you know about it, and roughly when will it be fixed?
3. Has your service been stable over the past while?

So a status page is not a monitoring dashboard. You don't need to put internal metrics such as CPU or queue length on it. Give conclusions that users can match against their own situation. For how users typically read status pages, see How to read the OpenAI and Claude status pages.

#How should you split components so they help for an AI service?

The rule: a failure boundary that users can tell apart is a component boundary. Users can't distinguish an "auth service" from a "billing service," but they can tell "I can't log in to the console" from "the API returns 5xx."

A typical AI API service can be split like this:

The data shows why model groups need their own components. Take AGI Plan as an example. In cdnping's snapshot from October 17, 2026, probing the agiplan.dev entry point from a Cloudflare edge node (Denver) gave an availability field of 100% (collection had only started that day, so the window covered about an hour and a half). In the same snapshot, AGI Plan's publicly reported availability, computed from real requests over the last 1 day, was about 77.3% for the "fast group," 100% for the "balanced group," and about 99.8% for the "frontier model group." A reachable entry point does not mean every model group works. If a status page has only a single "API" component, it would stay green in this situation.

We suggest putting upstream dependencies in their own section, labeled "third party," and excluding them from your own uptime.

#Where does status data come from: automated probes, real requests, or manual posts?

Each of the three sources has blind spots, so no single one is enough.

For the difference between probes and real-request statistics, see Synthetic monitoring vs. real user monitoring for AI.

cdnping's /status uses the first two sources plus upstream sync. It probes each vendor's official API entry point from Cloudflare's edge every 5 minutes, syncs the official status pages of OpenAI, Anthropic, Kimi (Moonshot AI), Groq, Cloudflare, GitHub and Cursor every 15 minutes, and keeps 30 days of history. The exact definitions are written up in our methodology.

Probe data can inflate or shrink the real picture, so state your definitions clearly. For example: between 16:40 and 18:05 Beijing time on 2026-10-17, cdnping made 242 probes from the Denver (DEN) node. In that window, the availability field for the Kimi Open Platform was 94.4% with a p95 latency of 1125 ms, and every other entry point was at 100%. The window is only an hour and a half and comes from a single node, so the number says "failures were observed from this location during this period." It can't be used to judge long-term stability. When your status page shows your own numbers, label the window and the probe location in the same way.

For real-request statistics, watch the denominator. AGI Plan's public definition is "successes / (successes + failures caused by the platform itself)." Only 5xx counts as a platform failure; a user's 401 or 429 does not. You may disagree with that definition, but you must write it down. When only a few requests arrive per hour at night, one failure can drag the ratio down sharply. Set a minimum request count, and below it show "insufficient data" instead of red. For how to measure this yourself and settle on a definition, see Measuring AI API uptime yourself.

#What does a minimal probe look like?

Suppose your API is at https://api.example.com. This command can go into any scheduled job and prints the status code, connect time and total time on each run:

curl -s -o /dev/null --max-time 10 \
  -w '%{http_code} %{time_connect} %{time_appconnect} %{time_total}\n' \
  https://api.example.com/v1/models

You can start with these rules: if no status code comes back (timeout, DNS failure, TLS failure), count it as a failure; 5xx counts as a failure; a 401 without a key means the gateway is working normally, so count it as a success. Use at least two probe locations in different regions, and call it an "entry point outage" only when both fail at the same time, so that one probe's network problem isn't blamed on you. For a fuller probing and alerting checklist, see A guide to availability monitoring for AI apps.

#How should you define status levels?

Fewer levels are easier to use. We suggest four levels plus a maintenance state, with the thresholds written on the page:

A few lessons:

• Let automation only raise the level. Returning to normal should need manual confirmation or several consecutive recovered windows, so the page doesn't flip between yellow and green.
• Vendors classify incidents very differently, so don't treat anyone else's distribution as a standard. In the official status pages that cdnping syncs, over the month from 2026-09-17 to 2026-10-17, OpenAI logged 4 major and 19 minor incidents, and Cloudflare logged 3 major and 19 minor. Most incidents are marked minor, and each vendor sets its own standard.
• Your availability target and level thresholds should line up. For how to compute targets and error budgets, see SLI, SLO and SLA: what's the difference.

#What should each incident update say?

Incident notices usually go through four stages: investigating, identified, monitoring, resolved. Each stage should answer a fixed set of questions:

Write the title as "symptom + scope." Most titles on official status pages follow this structure. Here are a few that cdnping synced:

• Increased HTTP 502 Errors (Cloudflare, minor, lasted 591 minutes)
• Network Performance Issues in London (Cloudflare, major, lasted 13 minutes)
• Elevated Errors in China Network Colos (Cloudflare, minor)
• Widespread feature degradation (OpenAI, major, lasted 146 minutes)

The first three show the impact and location at a glance. The last has a broad scope, so you need to click in to see the components. A template:

[Partial outage] Elevated request failure rate in the lightweight model group
Start time: 2026-10-16 14:05 (Beijing time)
Impact: About half of requests to the lightweight model group return 5xx. Other model groups and the console are normal.
Current progress: Identified as an elevated error rate at an upstream provider; traffic is being switched to a backup provider.
What users need to do: No configuration changes needed. If you have retry logic, we recommend exponential backoff.
Next update: within 30 minutes.

The times and ratios in the template are examples. AGI Plan's public data does show hours that look like this. In the snapshot cdnping mirrored, starting at 14:00 Beijing time on October 16, two consecutive hourly buckets had 722 and 877 failed requests, more than the successes in the same hours (664 and 455). For hours like these, the status page should have a matching incident record. Otherwise users will feel the page doesn't reflect reality.

Two more rules: put a "next update" time in every update, and if nothing has changed by then, post a "still working on it" update anyway. Don't rewrite earlier updates of a resolved incident; keep the original text and add clarifications.

#How long should history be kept, and should you offer RSS and JSON?

Keep history for at least 30 days, enough to cover the most common question, "has it been stable over the last month?" Keep longer if you can. cdnping's /status currently keeps 30 days, and because collection only began on 2026-10-17, the history is still short, which the page says plainly.

We suggest offering machine-readable outputs:

• JSON: for users' monitoring systems and bots. cdnping's open data endpoint /api/status is published under CC BY 4.0. AGI Plan provides hourly success and failure counts per capability group at https://agiplan.dev/api/status/requests?month=YYYY-MM, with no login required.
• RSS / Atom: for people who only want to subscribe to incident notices, with one entry per incident update.
• Webhook or email subscriptions: add these once your user base grows.

For JSON fields, you can use a structure like this (an example, not the definition of any existing API):

{
  "updated": "2026-10-23T12:00:00Z",
  "components": [
    {"id": "gateway", "status": "operational", "uptime_30d": 0.999},
    {"id": "group-fast", "status": "partial_outage", "uptime_30d": 0.98}
  ],
  "incidents": [
    {"id": "inc-001", "title": "Elevated request failure rate in the lightweight model group",
     "impact": "minor", "started": "2026-10-16T06:05:00Z", "resolved": null}
  ]
}

Once a field is public, avoid renaming it. Someone downstream will have hard-coded the parsing.

#What should you build it with, and do you need a server?

There are many open source and hosted options. We don't rank them here, only group them into three types by deployment style. Which to pick depends on what you're willing to maintain:

Whichever type you choose, insist on one thing: the status page and the monitored service must not share the same infrastructure, including DNS, CDN and database. If your main site is on Cloudflare, host the status page elsewhere, and vice versa. In mid-October 2026, Cloudflare's own status page logged failures in Workers Cron Triggers and Durable Objects. A probe running on those components could have had gaps in its data during those days.

#Pre-launch checklist

• Components are split along failure boundaries users can tell apart, with model groups listed separately
• Each component states its data source: probes, request statistics or manual
• Probes run from at least two regions, and a single-point failure doesn't turn the page red directly
• Request statistics have a minimum request count, and show "insufficient data" when the sample is too small
• Level thresholds and availability definitions are written on the page or in a methodology note
• The incident template includes symptoms, scope, start time (with time zone), what users need to do, and next update time
• Upstream dependencies are in their own section and not counted in your own uptime
• History covers at least 30 days and states the collection start date
• JSON and RSS are provided, with field names documented
• DNS, CDN and database are separate from the main service
• Run one drill: cause a component failure by hand and see how long the page takes to change color and the notice takes to go out

The last item is the easiest to skip and the best at exposing problems. After launch, you can compare your status page against a page like /down, which combines official status, API probes and user reports, to see whether the two agree. To see what the official status pages actually logged over a past period, read AI service incidents in September–October 2026.