Svix had 17 outages in the last 2 years totaling 1h 3m of downtime — averaging 0.7 incidents per month.
There were 17 Svix outages since September 30, 2024 totaling 1h 3m of downtime. Each is summarised below — incident details, duration, and resolution information.
Svix experienced elevated latency and a small number of errors in the US region between 19:45Z and 20:33Z due to a configuration change that enabled an experimental idempotency flow for an unexpectedly-large number of users. Approximately 12 requests saw 5XX errors during this period, and several thousand requests took longer than expected. This incident has been fully remediated.
A small fraction of API requests get errors and increased latency has been occurring occasionally in the EU region over the last 24hrs. Retries (including automatic retries by the SDK) should avoid the issue.
We experienced an issue where some customer in the EU region experienced elevated response times and error rates. The time frames when this occurred: 23:44 - 23:46, 00:05 - 00:13, and 00:38 to 00:48 UTC. This happened due to a significant spike in traffic (161x traffic the minute before), and the system not scaling fast enough to catch up. This affected customers routed to the same nodes that experienced this load.
The issue has been identified and a fix is being implemented.
It's been solved ~10mins ago, and the resolution has been confirmed. There have been a ~10 errors a minute (tiny fraction of the Svix API calls) and none affecting delivery or message ingestion.
The issue resolved once the AWS issues resolved.
This was automatically resolved, no action needed.
Load balancing misconfiguration caused ~90% of "create message" API calls to fail in the US region. The configuration was immediately reverted which returned to full functionality. Affected time: 2025-11-24 at ~21:23:00 UTC Svix SDKs have retries baked in and would in most cases transparently recover.
We've been asked multiple times today, so just sharing that Svix is *NOT* affected by the AWS outage.
Due to a race condition in the throttling code, some message may have been throttled for a much longer time than they were supposed to. The issue has been fixed and everything should be back in order. No action needed.
We are currently investigating this issue.
Issue has been identified and fixed. Monitoring.
This was indeed resolved earlier.
Due to a race condition in the throttling code, some message may have been throttled for a much longer time than they were supposed to. The issue has been fixed and everything should be back in order. No action needed.
We had a temporary increase in request latency for API calls reading from the message analytics db. Delivery was unaffected.
Messages are taking longer than usual to show in the log display. The delivery itself is unaffected.
We are currently investigating this issue.
We are continuing to investigate this issue.
The issue has been identified and a fix is being implemented.
A fix has been implemented and we are monitoring the results.
This incident has been resolved.
Sorry also for not updating the status page before, it looked ephemeral when it first surfaced. The issue was one API node that was having networking issues and was failing to connect to the rest of the systems and was timing out while at it. Only requests routed to this API node were affected, so retries would succeed. It's now been resolved.
We are currently investigating this issue.
Message delivery is not affected, but other API calls are seeing increased latency.
A fix has been deployed, we are monitoring to make sure everything is working as expected.
The issue is confirmed to be fixed.