"99.9% uptime" on an iMessage API status page usually means the HTTP endpoint accepted requests. That is not what you are buying. You are buying messages arriving on people's phones, and those are different systems with different failure modes.
The four layers, and which one matters
| Layer | Fails how | Who measures it |
|---|---|---|
| The API endpoint | 5xx, timeouts | Their status page |
| The queue | Accepted but never sent | Usually nobody |
| Your line | Throttled or flagged, silently | You, if you instrument it |
| Apple's network | Rare, brief, affects everyone | Nobody, really |
Layer three is the one that will hurt you
A throttled line usually returns 200 OK. The API is healthy, the status page is green, the dashboard says sent — and delivery has quietly collapsed. If you are not tracking delivered events as a ratio of sends, you will find out from a customer asking why you never replied. Why lines get flagged.
The metric worth asking for
Delivered rate: messages confirmed delivered, divided by messages accepted, over a rolling window, per line. It is the only figure that describes the thing you care about, and it is the figure almost no vendor publishes.
Ask anyway. A provider who can quote their median delivered rate and their p10 is a provider who measures it. One who redirects to uptime is telling you they do not.
Reading an SLA properly
Linq advertises a 99.95% uptime SLA and describes it as the only contractual one in the category. That is a real differentiator if the document holds up. Three things decide whether it does:
- What it covers. API availability, or message delivery? Almost always the former, which is the layer least likely to fail.
- What the remedy is. Usually a service credit proportional to the fee. If a lost week costs you far more than a month's subscription, the SLA is a signal of confidence rather than genuine cover.
- What is excluded. "Circumstances outside our control" that include Apple would exclude most of the ways this actually breaks. Read that clause specifically.
None of this makes an SLA worthless. A company willing to put a number in a contract has usually built to meet it. Just do not mistake the credit for insurance.
The week-long test
Worth more than every vendor claim combined, and it costs one month's subscription.
- Days 1–2. Send 20 messages a day to real recipients who expect them — staff, willing customers. Log every send and every delivery event with timestamps.
- Day 3. Measure delivered rate and median time to delivery. Anything under 95% delivered at this volume is a warning, not a fluke.
- Day 4. Break it on purpose. Send to a landline, an Android number, and a malformed number. Check the errors are distinguishable and documented.
- Day 5. Test the inbound path. Reply from three different phones and confirm every webhook arrives, verifies and is idempotent. What that handler should look like.
- Day 6. Push to double your intended daily volume and watch the delivered rate. If it drops, you have found your real ceiling — regardless of the published one.
- Day 7. Email support with a real question at a normal hour. Time the reply. You are buying that response time as much as the API.
Run it against two providers at once
Same messages, same recipients, same week. Comparative data beats absolute data, and both sandboxes are free. Almost nobody does this, and it is the highest-value week of evaluation available in this category.
What to instrument in production
- Delivered rate, rolling hour and rolling day, alerting on a floor you choose in advance.
- Time from send to delivered, p50 and p95. Creeping latency precedes throttling.
- Failure reasons grouped. A new reason appearing is a signal even when the rate has not moved.
- Reply rate. A drop can mean deliverability trouble before delivery events show it.
- A canary. One scheduled message to a phone you own, every hour, alerting if it does not arrive. Cheapest possible early warning.
The reliability you control
A meaningful share of reliability in this category is not the vendor's. Sending too fast, sending identical bodies, sending to cold lists and never getting replies will degrade delivery on the best infrastructure available. Pacing and message quality are reliability engineering here, not marketing.
And keep the fallback working. The most reliable architecture in this category is a good provider plus a tested SMS path plus customer records you own — not a better SLA.