What does 99.9% uptime mean for an iMessage API?

How much downtime does 99.9% allow?

99.9% uptime allows 43.2 minutes of downtime in a 30-day month and 8.76 hours in a 365-day year. Each extra nine cuts the allowance by a factor of ten.

Downtime = (1 − uptime) × minutes in the period: 43,200 in a 30-day month, 525,600 in a 365-day year.

The percentage alone does not say how downtime is counted, so two providers can both say 99.9% and mean different things; what other providers publish shows how the definitions differ.

Availability multiplies along the chain

An inbound text reaches your code through two links: ZeroSettle's line and your webhook receiver. If each is up 99.9% and their outages are independent, the pair is up about 99.8% (0.999 × 0.999): roughly 86 minutes of downtime a month. ZeroSettle's webhook retries after 1, 5 and 20 seconds cover a receiver that is down for seconds, not minutes; a longer outage needs the steps in what to build for critical messages.

Is ZeroSettle's 99.9% an SLA?

No. "99.9% uptime" is a stat on ZeroSettle's homepage, shown beside "10,000+ messages/week", and ZeroSettle publishes no SLA. The homepage gives the figure without a measurement period, a method, or a link to a status page.

A contractual SLA defines four things: the percentage, how and over what period it is measured, what is excluded, and the remedy when it is missed (usually service credits). ZeroSettle publishes only the first, as a stat, and its iMessage API Terms disclaim any warranty of uninterrupted operation:

ZeroSettle does not warrant that the services will meet your requirements or that their operation will be uninterrupted or error-free.

ZeroSettle iMessage API Terms, section 14

If your contract requires an SLA with credits, ZeroSettle is not a fit today. The homepage's Enterprise tier ("Custom pricing", "For high volume and compliance needs") lists no SLA among its inclusions; ask founders@zerosettle.io what terms are available. How reliable ZeroSettle is lists every published figure with its source.

Uptime, delivery and latency are different things

An API can be up while one message fails, and a send can be slow while everything is up. Uptime, delivery and latency are separate measures, and ZeroSettle publishes something different about each.

ZeroSettle's terms (section 7) say message status, delivery and read receipts "may be delayed, incomplete, or inaccurate", and: "Delivery of a message does not guarantee that it was read, and the absence of a receipt does not mean a message was not delivered." Even a contractual 99.9% would say nothing about whether one text reached one person. iMessage delivery status, webhook retries and latency covers each event.

How does ZeroSettle keep lines available?

ZeroSettle runs the line for you, pushes inbound so it never delays a send, sends one message at a time per line, limits new contacts to keep the number out of Apple's spam filters, and replaces a flagged number. ZeroSettle publishes nothing about redundancy or failover, so this page claims none.

ZeroSettle is an iMessage API: a real phone number on real iMessage, running on Apple hardware we operate for you, that your code texts customers from and hears back on through a bearer token and signed webhooks (what ZeroSettle is explains the product).

• Nothing for you to host. "We run the Apple hardware and set up the number for you." Keeping the line up is ZeroSettle's job; keeping your webhook receiver up is yours.
• Inbound never blocks a send. "Inbound is pushed; nothing polls for it, so inbound never delays a send."
• One send at a time per line. Concurrent sends queue and surface as line_busy after about 12 seconds of waiting.
• Limits guard against the outage uptime does not measure. "Repeated messages to people who never answer are the fastest way to get a number flagged by Apple: when that happens every send fails, to everyone." The API can be up while a flagged number fails every send.
• Flagged numbers are replaced. The homepage says: "across more than 10,000 messages a week we have seen it happen only twice", and ZeroSettle replaces the number "right away at no extra charge", with your API token, webhook and code unchanged. Recipients see a new number; what happens when a number is flagged covers the rest.

How do failures show up in your code?

ZeroSettle reports a failed send as an HTTP error with a machine-readable error.code and a stored failed record, and a failed webhook delivery in last_delivery, so downtime is visible to your code instead of silent. "Every attempt, successful or not, is stored (record.status is sent or failed)."

This helper retries line_busy and the 503s, which the docs say to retry, plus network errors and 5xx responses that carry no ZeroSettle error code (a proxy error page, for example). Anything else, such as new_contact_limit, a 403 opt-out or a 502 send_failed, goes back to the caller.

import os, time
import requests

BASE = "https://portal.zerosettle.io"
TOKEN = os.environ["ZEROSETTLE_TOKEN"]

def send(to: str, text: str, attempts: int = 5) -> dict:
    delay, wait = 2, 0
    for _ in range(attempts):
        time.sleep(wait)                            # 0 on the first attempt, then the backoff
        try:
            r = requests.post(f"{BASE}/api/imessage/send",
                              headers={"Authorization": f"Bearer {TOKEN}"},
                              json={"to": to, "text": text},
                              timeout=120)          # a text can take up to about 75 s
        except requests.ConnectionError:
            wait, delay = delay, min(delay * 2, 60)
            continue
        if r.ok:
            return r.json()                         # record.status == "sent"
        try:
            err = r.json().get("error") or {}
        except ValueError:
            err = {}                                # not ZeroSettle's JSON, e.g. a proxy error page
        code = err.get("code")
        if code == "line_busy":                     # 429: another send held the line
            wait = float(r.headers.get("Retry-After", 2))
        elif code in ("phone_offline", "phone_timeout") or (r.status_code >= 500 and not code):
            wait, delay = delay, min(delay * 2, 60)  # 503: back off
        else:
            raise RuntimeError(f"{r.status_code} {code}: {err.get('message')}")
    raise RuntimeError("send still failing after retries: use your second channel")

GET /api/imessage/line returns last_delivery, the newest webhook delivery with ok, status_code, attempts and error, and the live stream reports every attempt as a delivery event. The full error table is in the docs.

What other providers publish

Messaging providers publish a contractual SLA with credits, a marketing number, a status-page measurement, or an explicit disclaimer. Every figure below was read on the provider's own page on October 8, 2026.

Sources are listed at the end of the page. Competitor figures change; check each provider's page before relying on one.

Compare definitions, not digits: Twilio's 99.95% is measured per calendar month, ignores outages shorter than five continuous minutes and scheduled maintenance, and pays credits; Linq's status page shows 99.93% for its V3 API from July to October 2026; and ZeroSettle's 99.9% is a reported stat with no stated method. ZeroSettle vs Linq compares those two iMessage providers in depth.

What to build for critical messages

Design for the minutes a 99.9% figure allows: retry the right errors, make your webhook receiver idempotent, watch last_delivery, and send anything that must arrive over a second channel too.

1. Retry with backoff, then hand off. Cap the attempts, as the helper above does, and never retry 403 recipient_opted_out.
2. Make the receiver idempotent. Answer 2xx within 10 seconds and queue the work. Retries carry the same message.id and event, so dedupe on that pair, and order by message.id if order matters.
3. Alert on last_delivery. Check GET /api/imessage/line on a schedule and page your team when last_delivery.ok is false.
4. Count message.failed as not sent. Never mark an alert or reminder delivered on a failed record.
5. Keep a second channel for messages that must arrive. On-call alerts over iMessage shows a relay that falls back to another pager when a send fails.

The webhook steps in the ZeroSettle docs cover signature checks and a signed test event. Plans are on the homepage pricing section, you can get a number from the console, and the reliability and trust hub collects related pages.