Svix Outage History

This incident has been resolved

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.

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.

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.

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.

The issue is confirmed to be fixed.