Current status
Live state of each service, with 90 days of uptime history.
Scheduled maintenance
Planned work, listed by month for the months ahead.
Previous incidents
What went wrong, when, and how it was resolved.
What’s monitored
Each service shows its current status and a 90-day uptime bar. Hover over a day for that day’s details.
What each status means for your integration
Planned maintenance
Planned work is announced on status.spenza.com/maintenance, grouped by month for the current month and the months ahead. Each entry gives the window and which service is affected. Check it before you:- launch an integration or roll out a release that depends on the API,
- run a bulk job such as mass eSIM provisioning, plan purchases or user imports,
- schedule a customer-facing event that relies on activations or number assignments going through.
The months shown say No maintenance scheduled when nothing is planned. If you need a quiet period guaranteed around a launch, email support@spenza.com in advance.
Get notified
The status page publishes incident and maintenance announcements as an RSS feed:The feed is empty until the first announcement. It lists only incidents and planned maintenance, so it has no items until one is posted, and some readers show an empty feed as “no updates” or refuse to add it. Email and SMS subscriptions aren’t offered on the status page today. Until the feed has history, bookmark status.spenza.com and check it as described below.
Is it an outage or my integration?
- Check status.spenza.com. If the API is shown as Degraded, Downtime or Maintenance, you’re probably affected by that. Back off and wait for it to recover.
- Look at the status code.
400,401,403,404and409come from the request itself and won’t fix themselves. Check theerror.codeagainst Errors.429means you’ve hit a rate limit (see Rate Limits), not that the API is down. - The status page says Operational but you’re getting repeated
5xxor timeouts? Retry aGETwith backoff. If it keeps failing, email support@spenza.com with the details listed on Support: the request, the response, and a UTC timestamp.
Building for resilience
Plan for outages up front, so an incident slows your integration down rather than breaking it:- Retry
5xx, timeouts and429with exponential backoff and jitter, and give up after a bounded number of attempts. Don’t retry other4xxresponses unchanged. See Errors → Retry recommendations and Rate Limits → Recommended backoff strategy. - Send an
Idempotency-Keyon writes that support it, so a retry after a timeout can’t buy, provision or top up twice. See Core Concepts → Idempotency. - Keep polling async operations. A
transactionIdstays valid through a blip, so resume pollingGET /api/v3/transactions/{transactionId}instead of resubmitting the original request. - Queue work during an outage and replay it once the status page shows the API as recovered, rather than dropping it or hammering the API.
- Use a circuit breaker. After repeated failures, stop calling for a short cool-down and show your users a clear “temporarily unavailable” state.

