Methodology
How Apselog measures AI provider health, what our status labels mean, and where to find each provider’s authoritative status.
Apselog measurements are advisory, not authoritative.
Our probe results describe what Apselog measured from our probe location at the time of probe. They are not statements made by the providers about their own services. For canonical incident determinations, see each provider’s official status page (linked below). Do not use Apselog as the sole input to automated production routing, failover, or financial decisions.
How we probe
- Endpoint: for each provider we call the provider’s public
/v1/modelsmetadata endpoint (or equivalent control-plane GET). These calls are documented as metadata-only — no tokens are consumed and no model inference runs. - Cadence: every 2 minutes on the Free tier; every 60 seconds on Pro/Team. Probes hit the provider from a single geographic location (currently Germany, Hetzner Falkenstein).
- Timeout: probes abort at 10 seconds. A timeout is recorded as
TIMEOUTstatus; the provider may be fully operational from another region. - Identification: all probes send a User-Agent of
Apselog-Monitor/1.0so providers can identify the source if needed.
What our labels mean
- OK / Operational
- Our last probe received the expected HTTP status (typically 200) within 5 seconds. Does not guarantee model quality, per-request behavior, or availability from your users’ location.
- Degraded
- Our last probe received the expected status but latency exceeded our 5-second threshold, OR we received a 4xx response other than auth-related codes. This is our measurement; the provider may classify the same event differently.
- Errors / Down
- Our last probe received a 5xx response or the request timed out. Again, this is our measurement from a single probe location. The provider’s official status page is the canonical source.
- Unknown
- We have not received a recent probe result. This is a measurement gap, not a claim about provider state.
Canonical sources of truth
For authoritative incident determinations, defer to each provider’s official status page. Apselog measurements do not replace these sources.
- OpenAIstatus.openai.com
- Anthropicstatus.anthropic.com
- Google AI (Gemini)status.cloud.google.com
- Mistralstatus.mistral.ai
- Groqgroqstatus.com
- xAI (Grok)status.x.ai
- Replicatereplicatestatus.com
- Fireworks AIstatus.fireworks.ai
- AWS Bedrockhealth.aws.amazon.com
- Google Vertex AIstatus.cloud.google.com
- Coherestatus.cohere.com
- Together AIstatus.together.ai
AI-drafted incident summaries
When an anomaly is detected, Apselog can generate an AI-drafted incident summary using a Claude Haiku model. These drafts:
- Are explicitly labelled “Apselog AI” on the status page.
- Are written using measurement-based language only — they describe what our probe observed, not what the provider is doing.
- Require human approval by the status-page owner before publication.
- Are advisory; not the provider’s official statement.
Corrections and updates
If you believe an Apselog measurement is incorrect — or if a status-page incident on Apselog misrepresents your service — contact [email protected]. We will review the probe history and the published claim, post a visible correction notice on the affected status page within one business day, and (if warranted) remove the incident from the public timeline.