"99.99% uptime" appears on every data vendor's page, and it's one of the least examined numbers in procurement. For a dispatch desk, an airline ops centre, or anything where a stale aircraft position becomes an operational decision, the difference between uptime tiers is measured in minutes per month — and more importantly, uptime is often the wrong metric for flight data entirely. Here's what these guarantees actually mean and what to interrogate before you sign.
The downtime math
Start with the arithmetic, because the nines compress in a way intuition doesn't:
| Uptime | Downtime per year | Downtime per month |
|---|---|---|
| 99% | 3.65 days | 7.2 hours |
| 99.9% ("three nines") | 8.76 hours | 43.8 minutes |
| 99.95% | 4.38 hours | 21.9 minutes |
| 99.99% ("four nines") | 52.6 minutes | 4.38 minutes |
| 99.999% ("five nines") | 5.26 minutes | 26 seconds |
Two things fall out of that table. First, the jump from three to four nines is a 10× reduction in allowed downtime — an enormous engineering difference that shows up directly in price. Second, four nines allows less than five minutes a month: that is not a target you hit with careful ops, it's one you hit with redundancy at every layer and automated failover, because five minutes is shorter than most human response times.
Where we stand, plainly: SkyLink's contractual commitment on Enterprise is 99.9% uptime, backed by response-time commitments and service credits. We publish that rather than the bigger number because an SLA you can actually be held to is worth more than one that reads well on a comparison page.
Why uptime is the wrong headline metric for flight data
Here is the thing that catches operations teams out: an API can be 100% available and still be useless. If the endpoint returns 200 OK in 40 milliseconds with a position that's eleven minutes old, every uptime dashboard stays green while your operational picture is wrong. Availability measures whether the service answers. It says nothing about whether the answer is current.
For flight data, the metrics that actually govern operational risk are:
- Data freshness / staleness. How old is the newest position for a given aircraft? This is the number that should be on your dashboard. Every ADS-B record from SkyLink carries
last_seen, so you can measure staleness yourself rather than trusting a claim. - Coverage. Availability of the service versus availability of the data for the region you care about. A feed can be perfectly up and blind over the North Atlantic.
- Latency percentiles, not averages. A p50 of 80 ms with a p99 of 9 seconds is a bad service that looks good in a mean.
An SLA that guarantees availability but says nothing about freshness has guaranteed the least important half. Ask explicitly whether staleness is covered, and if so, how it's measured.
Degraded mode: what happens when something breaks
Mature systems don't fail binary — they degrade. What matters is whether the degradation is visible to you. Two patterns worth demanding:
Explicit fallback signalling. When a component is unavailable, the response should tell you it's operating in a reduced mode rather than silently substituting a lower-quality answer. Ours does this concretely: if the ML model behind flight time predictions is temporarily unavailable, the service may fall back to a distance/speed calculation — and the model_version field tells you that happened, so you can audit or discard it. That's the property to look for generally: a field you can branch on, not a silent downgrade.
Health endpoints you can poll. Before starting a polling loop, you should be able to ask the feed how it's doing. SkyLink exposes GET /adsb/health for exactly this — connection status and active aircraft count — so your own monitoring can detect a degraded feed independently of the vendor's status page.
Failover, on your side of the line
No vendor SLA removes your obligation to design for their failure. For mission-critical operations, assume the feed will be unavailable at the worst possible moment and build accordingly:
- Cache last-known-good, with an age stamp. Serve the cached picture during an outage and display its age prominently. A visibly stale position is safe; an invisibly stale one is not.
- Fail loudly in the UI. Operations staff must be able to see instantly that they're looking at degraded data. Silent staleness is the failure mode that causes bad decisions.
- Independent monitoring. Poll a health endpoint and alert on staleness thresholds yourself. Don't discover an incident from the vendor's status page.
- Understand service credits for what they are. Credits are a refund, not a remedy — they compensate you for the bill, never for the operational consequence. Price the consequence separately.
What to actually ask a vendor
Turn the sales conversation into a checklist:
- What's the contractual uptime figure, and is it in the MSA or just on the marketing page?
- How is downtime measured — whose monitoring, at what interval, from which regions?
- Are service credits automatic, or must you claim them within a window?
- Is data freshness covered by any commitment, or only availability?
- What's the documented degraded-mode behavior, and how is it signalled in the response?
- What are the response-time commitments for incidents, and is support 24/7 or business-hours?
- Is there region-local serving or data residency, if your compliance requires it?
For reference, Enterprise plans here include the 99.9% contractual guarantee with service credits, 24/7 incident coverage with a named account manager and a shared Slack channel with our engineers, region-local endpoints and configurable data residency, plus SOC 2 reporting and DPAs handled during onboarding.
None of that is a substitute for testing the data yourself — which is what the flight data evaluation methodology is for, and why teams weighing this against running their own stack should also read the build vs buy analysis.
Talk to us about Enterprise if you need a contractual SLA, or start with the free trial and measure freshness and coverage for yourself before any commitment.