The trouble with API keys that never expire
A key issued years ago, never rotated, and still valid today is not a convenience. It is a liability nobody has actually looked at in years.
The problem with SLA language nobody can act on
An SLA that promises 99.99 percent uptime sounds precise and reassuring until you read what happens when it is missed. Often the remedy is a small service credit, calculated as a fraction of a fraction of your monthly bill, available only if you notice the outage yourself, document it precisely, and file a claim within a narrow window, through a process that costs more staff time to complete than the credit is worth. The percentage on the sales page and the actual protection behind it are two very different things.
This is not really about uptime numbers being dishonest. Most providers who publish 99.9 or 99.99 percent are probably describing real historical performance. The problem is that an uptime percentage, on its own, describes the provider's track record, not what happens to you specifically when that track record has a bad day. A customer reading an SLA wants to know what recourse looks like during an outage, not just what percentage of the year the service is expected to work.
We would rather a status commitment be judged by what a customer can actually do with it than by how the headline number looks on a sales page. That starts with visibility you do not have to request: quota headers on every response, so you know your own standing in real time, and clear, published documentation of rate limits and error codes rather than a document you only read after something already broke.
A workable SLA, if a provider is going to offer one at all, has to specify a remedy that is proportionate and easy to claim, not a technicality that discourages anyone from actually asking for it. If the credit for a missed uptime target is genuinely too small to matter and the claims process is genuinely too slow to bother with, the SLA is functioning as a marketing artifact, not an operational promise. It exists to be printed, not to be used.
We think the more honest thing a provider can do is be plain about what actually happens during degraded service or an outage: what gets communicated, when, and through what channel, rather than leading with a percentage that implies a guarantee it cannot really back with a workable remedy. A status page that tells you the truth quickly is worth more to an integration than a contractual number that only pays out in theory.
None of this means uptime commitments are worthless. A provider willing to publish a real number and stand behind a real, usable remedy is doing something meaningfully different from one that publishes an impressive percentage and a process designed never to be invoked. The difference is not in the number of nines. It is in whether the promise behind the number is something you could actually collect on, in a bad week, without it costing more effort than the outage itself.