SLA · letme.dev · from 20 October 2026
letme.dev service level
letme.dev should be up 99.9% of every calendar month, and when it's down for longer than 15 minutes we write up why. This page says how that's measured, what counts as down, and where the measuring falls short today.
This applies from 20 October 2026. It covers letme.dev, its HTTP API and its MCP server at https://letme.dev/mcp. The directory at www.anchorterminal.com isn't covered yet, because the status page doesn't probe it.
What we commit to
- 99.9% availability each calendar month, in UTC. That's about 43 minutes down in a 30-day month and 44 in a 31-day one.
- A written post-mortem for any outage longer than 15 minutes. What broke, when, for how long, why, and what we changed so it doesn't happen the same way again.
- At least 90 days' notice before a breaking change to letme's API or its MCP tools. A breaking change is one that makes a request or a tool call that works today fail or mean something else. New fields, new tools and new filters aren't breaking changes and can ship without notice.
letme is free to use, so a month under 99.9% earns no money back. What you get instead is the record on /status/ and the post-mortem.
How it's measured
The status page probes letme.dev every five minutes, with the same pollers that watch every listing in the directory, and shows uptime by day for the last 31 days and every outage in the last 90.
Down means the same thing here as on /status/. An outage starts at the first of three or more failed probes in a row and ends at the next probe that answers. A month's availability is the time inside those outages, taken away from the month's minutes.
That rule has a cost you should know about. One or two failed probes followed by one that answers aren't an outage, so a failure can last up to about 15 minutes without being counted.
What it can't see yet
The probes run on the same machine as letme.dev. When the whole machine is down, nothing probes it, so nothing is recorded. /status/ says this too.
A day with fewer than nine in ten of a full day's 288 probes says so on /status/, rather than counting as clean. When we work out a month, the time any missing probe would have covered counts as down, not up. We'd rather understate the number than claim minutes nobody watched.
Probes from a second place, off this machine, are the fix. Until they run, the two limits above stand and this page will keep saying so.
What's excluded
Nothing. Planned maintenance counts as downtime like anything else, and so does a restart. A deploy starts the new process and hands it new connections before the old one stops, so it shouldn't show up as an outage, and if it does, it counts.
Where post-mortems and notices go
Post-mortems and notices of breaking changes are published in the changelog, where deprecations have always been announced at least 90 days ahead. Every outage stays listed on /status/ for 90 days with its start, end and length, and /status/ links here and to the changelog.
To tell us letme.dev is down when /status/ doesn't show it, file it on the public issue tracker, where we reply in the open, or use the contact form. A security problem goes to security.txt, never anywhere public.