Status methodology

Updated November 9, 2026 · The status page is not an SLA.

SourcesCopy Anchor Link

Two inputs feed status.logits.com. Our API router records both when a request completes.

• Synthetic probe: one request per model per minute. Drives health, uptime and the history bars.
• Customer traffic: drives latency and throughput, and can corroborate a missing probe in the same minute. Probe requests are excluded from it.

The page reads a public endpoint, GET https://api.logits.com/status/v1/summary?window=24h, through a CDN cache that keeps a copy fresh for 15 seconds and serves it for up to a minute more while it refreshes. The page shows when the current status was last checked, asks again when its copy is over 90 seconds old, and warns when the snapshot on screen is over 2 minutes old. Each card says when its window's own figures were built: the 24h, 7d and 30d windows are rebuilt every 5, 30 and 60 minutes, while the current status is refreshed every 30 seconds. window accepts 30m, 1h, 24h, 7d and 30d. The response contains aggregates only, with no account, key or request identifiers. Fields such as health_source and uptime.source name the input behind each value.

ProbeCopy Anchor Link

A scheduled job sends one streaming chat completion per public model every minute to https://api.logits.com/v1/chat/completions, with a normal API key and normal routing. Its configured model list matches the public API allowlist; it does not call the summary endpoint before probing.

POST https://api.logits.com/v1/chat/completions

{
  "model": "<public model id>",
  "messages": [{
    "role": "user",
    "content": "[run-id <16 random hex characters>]\nJanet's ducks lay 16 eggs per day. She eats three for breakfast every morning and bakes muffins for her friends every day with four. She sells the remainder at the farmers' market daily for $2 per fresh duck egg. How much in dollars does she make every day at the farmers' market?\n\nSolve this step by step, then give the final numeric answer on the last line as 'Answer: <number>'."
  }],
  "max_tokens": 256,
  "temperature": 0.6,
  "top_p": 1.0,
  "reasoning_effort": "low",
  "stream": true,
  "stream_options": {"include_usage": true}
}

• Prompt: a fixed GSM8K word problem. It yields more than the 50 output tokens that throughput and ITL require.
• run-id: a random prefix on every prompt that keeps provider prefix caches cold.
• Timeout: 20 seconds per request, no retries, up to four models in parallel.
• Schedule: one run at a time. A minute gets no probe if the previous run is still going or the run cannot start within 30 seconds.

A probe succeeds when the API recorded it as completed with HTTP 200 and at least one output token. The job also checks the stream itself (event format, a non-empty delta, the closing [DONE]); those results go to its logs only.

From a model's first probe on, every whole minute should hold one result. Only when that result is absent can at least 3 eligible customer requests for the same model in that exact minute supply the normal 80/50 minute verdict. An existing probe result always wins, including a failed, timed-out or cancelled probe. Without sufficient eligible evidence, the missing minute remains down. The current and previous minute are not expected yet because their probe may still be running.

HealthCopy Anchor Link

Each card shows operational, degraded, down or unknown, taken from the first input below that has enough data:

If no input qualifies, the status is unknown. An input with at least 3 attempts and no successes is down. Missing probe results in the last 5 minutes follow the same exact-minute evidence rule. Uncorroborated gaps count as failures; a degraded live substitute contributes half a success to these health bands.

UptimeCopy Anchor Link

Uptime is counted per minute with OpenRouter's bands: a minute is up at 80% success or more, degraded at 50% or more and down below 50%.

• Probe minutes are used when the window has at least 10 judged minutes. A recorded probe minute is up if it succeeded and down if it failed; an absent result follows the exact-minute evidence rule above.
• Customer minutes are the fallback. A minute counts only with at least 3 eligible requests, and the fallback needs 60 counted minutes (30 in the 1-hour window).

uptime = up / (up + degraded + down). The API also returns served_pct, which treats degraded minutes as available, and missing_minutes, the uncorroborated missing probe minutes still counted as down. live_fallback_minutes counts absent probe minutes replaced by eligible live verdicts, including degraded or down verdicts. Both counters also appear on hour/day buckets. For a model added during the window, only the minutes after its first probe count.

HistoryCopy Anchor Link

The bars under each card follow the selected window: one bar per hour for 1h (the two clock hours its 60 minutes overlap) and 24h, one bar per UTC day for 7d and 30d. Hourly and daily bars apply the same minute rule. Each day or hour picks its input separately: probe minutes if it has at least 10, otherwise customer minutes if at least 10 were counted, otherwise whatever minutes it has.

• Up: at least 90% of counted minutes up. Degraded: at least 75%. Down: below 75%.
• Partial: a day with fewer than 720 counted minutes, or an hour with fewer than 60.

At the 90% line, a day with up to 144 down minutes still shows as up. Each bar's tooltip gives its exact uptime.

Latency and throughputCopy Anchor Link

Computed from customer traffic in the selected window and timed at our router, which leaves out network time between the client and the router.

TTFT, decode speed and ITL are measured only on streamed requests. A non-streamed request gets its whole answer in one write, so it has no first token to time and no gap between chunks. The TTFT card therefore also shows the share of the window's delivered requests that streamed (latency_basis.streamed_pct in the API): a low share means those figures describe only a small part of the traffic, while duration still covers every delivered request. The share is a disclosure, not a correction — the latency figures themselves are unchanged. When a model has too few streaming samples, the card falls back to the streaming status probe, whose short prompt and 256-token cap are not comparable with live traffic; it then shows probe in place of the share (ttft_source in the API), because the probe value does not describe the window's traffic.

Below the minimum, a card uses the window's probe samples instead (at least 10); with fewer, it shows no value. Cards show decode speed. Output throughput appears only in the OpenRouter comparison.

TTFT and duration percentiles are ordinary: p90 is slower than p50. Speed percentiles follow OpenRouter: pN is the speed that N% of requests met or exceeded, which puts p90 below p50.

Which requests countCopy Anchor Link

• Success: the request completed and returned at least one output token.
• Failure: server errors, timeouts, interrupted streams, empty responses, and 429s from our overall capacity.
• Excluded: client errors such as invalid parameters, cancellations, and per-account limits (rate limits, budget, balance). The API reports each as its own percentage.

Success rate is successes divided by successes plus failures, per request, and needs at least 50 eligible requests. A completed request with no recorded output token count is unknown and counts as neither.

OpenRouter comparisonCopy Anchor Link

Each card ranks our value among the providers OpenRouter lists for the same model. The windows are fixed to match OpenRouter's fields, whatever window is selected:

• Data: OpenRouter's documented GET /api/v1/models/{permaslug}/endpoints, read by our server at most every 2 minutes. After a failed read the previous result stays for up to 10 minutes. Browsers never call OpenRouter.
• Providers: endpoints are merged by provider name. Standard-tier endpoints are preferred over flex, priority, fast, spot and batch, and each row takes the provider's best value. Entries named Logits are excluded.
• Rank: 1 plus the number of providers strictly better than us; equal values share a rank. The median excludes us. A row shows no rank if our window had to widen for lack of traffic.

The two sides are timed at different points. OpenRouter measures at its gateway, including its hop to the provider; we measure at our router, which favors us. Our uptime comes from one probe per minute, OpenRouter's from customer requests. The comparison does not claim that we are faster than any provider.

LimitationsCopy Anchor Link

• One probe location, inside our production cluster. Network problems between other regions and us do not show up.
• Small probe workload: a short prompt, a 256-token cap, a cold cache and one request at a time. Long context, tool calls and heavy load are not exercised.
• The card's status comes from the probe whenever probe results exist; the customer success rate is used only without them. If customer requests fail while the probe still succeeds, for example when only very long prompts fail, the card stays operational.
• One failed probe marks its minute down. OpenRouter judges a minute from its customers' requests in that minute, a different sample size.
• A failure of the probe job with fewer than 3 eligible same-model, same-minute customer requests remains down. Cancellations such as customer 499s, client errors, per-account throttling and unknown classifications cannot corroborate a gap. Without eligible live traffic, a monitor failure and an API/ingress blackout that records nothing cannot be distinguished; both remain down.

ChangesCopy Anchor Link

• November 9, 2026: the history bars follow the selected window (hourly for 1h and 24h, daily for 7d and 30d), the uptime tooltip states the missing-probe rule above, and the page warns when the snapshot it shows is over 2 minutes old instead of reading the cache's age as quiet traffic.
• November 7, 2026: the TTFT card shows the share of delivered requests that streamed, and the latency table states that TTFT, decode speed and ITL cover streamed requests only.
• November 5, 2026: missing probe minutes use sufficient eligible same-model, same-minute live evidence consistently in uptime, history and health. Uncorroborated gaps remain down; recorded probe failures cannot be overridden. Earlier, all missing minutes counted as down after initially being left out.