Spreedly Incident History

1. postmortemSep 9 · 21:50 UTC

   ### _September 9, 2026_ — _Elevated Error Rates Affecting Transaction Processing_ ### ‌High Level Summary On September 2, 2026, between 14:35 and 15:19 UTC, Spreedly experienced a period of elevated error rates affecting a subset of transaction requests across endpoints. The issue lasted approximately 44 minutes and was caused by an infrastructure-level issue with our database platform. Our team identified and resolved the issue the same day. ### What Happened During a routine schema update, a defect in our underlying database platform caused one of our database nodes to become unavailable. This temporarily reduced the redundancy for a portion of our transaction data, which led some requests to either time out or receive a system error response \(HTTP 500\) instead of processing normally. Our team worked directly with our database vendor to identify the root cause and confirm full recovery of the affected infrastructure. ### Next Steps We've identified the underlying cause as a known issue in our database vendor's software. A vendor-supplied fix is scheduled to be applied during normal scheduled maintenance. In parallel, we are adding additional monitoring to detect this class of issue earlier, and adjusting our internal procedures around database maintenance work to further reduce the risk of a similar incident going forward. -The Spreedly Team

Reported by Spreedly on their status page.

1. postmortemSep 3 · 20:57 UTC

   ### High Level Summary On July 27, 2026, Spreedly experienced intermittent errors on a subset of transaction requests, including purchases, authorizations, and webhooks. ### What Happened A database migration updated the schema of an internal service that manages stored payment methods. This caused errors on existing connections referencing a stale cache. We rolled back the change and cycled those connections, fully resolving the issue. ### Next Steps We are reviewing our schema migration process to add additional safeguards that will prevent this class of issue from recurring, and are improving automated testing coverage for this scenario. We have added auto-retry and recovery mechanisms so that if a connection does reference an outdated schema it will not affect transactions going forward.

Reported by Spreedly on their status page.

1. postmortemSep 3 · 20:55 UTC

   ### Service Disruption on Transaction Endpoints ### ‌High Level Summary On August 14, 2026, Spreedly experienced a brief service disruption affecting some transaction-related API endpoints for approximately 20 minutes \(4:06 PM – 4:26 PM ET\). During this window, some requests to endpoints involving transaction lookups, captures, voids, credits, and payment method operations may have received error responses. The issue was identified and resolved quickly by our engineering team. ### What Happened A routine database schema update caused a subset of existing database connections to reference outdated schema information, resulting in intermittent errors on affected requests. Once identified, our team refreshed the affected database connections, which fully resolved the issue. ### Next Steps We are reviewing our schema migration process to add additional safeguards that will prevent this class of issue from recurring, and are improving automated testing coverage for this scenario. We have added auto-retry and recovery mechanisms so that if a connection does reference an outdated schema it will not affect transactions going forward.

Reported by Spreedly on their status page.