How the reliability score is computed

The score in one paragraph

Every tracked API gets one reliability score — a single number from 0 to 100 where higher means fewer surprises for the developers who depend on that API. It blends three inputs with fixed weights:

• Uptime — 50%, measured, not reported (trailing 90 days)
• Latency — 25%, p99 response time (trailing 90 days)
• Developer sentiment — 25%, from public conversations on X, GitHub and Discord (trailing 30 days)

The inputs ship next to the score on every tracker page, so the number is auditable rather than taken on faith.

Uptime: measured, not reported

api.gripe probes each tracked API’s public endpoints directly, around the clock, and computes uptime as the share of probes that complete successfully over the trailing 90 days. Vendor status pages are never an input — they say “all systems operational” right up until they don’t, and independent measurement is the whole point.

Latency: p99, not best-case

The same probes record response times, and the score uses p99 — the response time the slowest 1 in 100 requests experiences, the tail that pages you at 2 a.m. Averages flatter vendors; the tail doesn’t. Latency uses the same trailing 90-day window as uptime.

Sentiment: the room, read

Hard numbers miss the gripes that never reach a monitoring dashboard: silent breaking changes, rate limits nobody documented, support threads that go quiet. api.gripe reads public developer conversations on X, GitHub and Discord — outage reports, breaking-change complaints, support horror stories — and turns them into a sentiment signal over the trailing 30 days, so recency counts. Sustained patterns move the score; a single stray post registers as noise — the sentiment sub-score holds at neutral until at least 10 relevant mentions exist in the window.

From inputs to score

Each input first becomes its own 0–100 sub-score, then the three sub-scores are blended with the fixed weights above into the published 0–100 score — score = 0.5 × uptime + 0.25 × latency + 0.25 × sentiment, rounded to the nearest whole number.

• Uptime sub-score: the uptime percentage itself — successful probes divided by total probes over the trailing 90 days, times 100.
• Latency sub-score: the p99 response time mapped linearly onto 0–100, inverted so faster is better: 100 points at 100 ms or faster, 0 points at 4,000 ms or slower, proportional in between — a 2,050 ms p99 scores exactly 50.
• Sentiment sub-score: every public post or comment mentioning the API in the trailing 30 days is classified positive, neutral or negative; net = (positive − negative) ÷ total mentions; sub-score = 50 × (1 + net). An all-positive window reads 100, an all-negative one reads 0, an even split reads 50. Below 10 relevant mentions the sub-score stays at the neutral 50.

Because the weights and the maps are fixed, scores are comparable across APIs and across time — a score only moves when the underlying measurements do. Category pages rank the APIs in a category by this same score, so the payments and AI/LLM hubs run on exactly the method on this page.

Update cadence

Probes run continuously; scores, uptime and latency figures are recomputed daily. Every number on every page carries the date it was measured — nothing stale is shown as current.

What the score is not

• Not sponsored. Vendors can’t pay to move a score, and api.gripe is not affiliated with the APIs it tracks.
• Not self-reported. Inputs come from api.gripe’s own probes and public developer conversations — never vendor-supplied data.
• Not a security or code-quality verdict. The score measures reliability: uptime, latency and the day-to-day experience of building on the API.

Dispute a score

Scores are wrong sometimes — that’s what publishing the inputs is for. If a score doesn’t match the underlying data, email support@api.gripe or use the contact page. Corrections are made against the method on this page, not quietly.

Tracking starts at launch. Join the waitlist to get every score the day it lands, or read about api.gripe.