Uptime numbers are only useful if they're honest. Ours are measured by an external service (not us), and we publish the raw numbers rather than a rounded-up display figure. If we say 99.98%, that's the number to at least four sig-figs.
Current rolling figures
Measurement methodology
- External synthetic monitor pings ladle.chat/api/healthz every 60 seconds from three geographies (US-east, US-west, EU-west).
- A ping counts as failed if it (a) returns a non-2xx status, (b) times out after 10 seconds, or (c) returns malformed JSON.
- Uptime = (successful pings) / (total pings) × 100.
- We do not exclude scheduled-maintenance windows from the calculation. If we bring the app down for a deploy, it counts against uptime.
SLA commitment
The published SLA target is 99.5% monthly. For business customers, monthly uptime below 99.5% triggers pro-rata service credits on request (see /business FAQ). Consumer subscriptions do not have contractual uptime commitments but receive the same monitoring and public reporting.
What isn't counted here
- Anthropic API downtime is only counted when it breaks LADLE end-to-end. If Anthropic degrades but we serve cached / previous responses successfully, that's not counted against LADLE.
- Individual-user network issues (their ISP, their VPN blocking our domain, etc.) are not counted. If our monitor from three geographies succeeds, we call it up.
- Feature-specific bugs that don't affect the health-check endpoint. Those show up on /status/incidents but don't move the uptime figure.
Historical breakdown
MONTHLY DETAIL · /STATUS/INCIDENTS FOR FULL WRITE-UPS