Post-incident report: Contact services disruption — 26 August 2026
Summary
On 26 August 2026, between 09:34 and 13:40 UTC, a database server hosting contact data for a subset of Brevo accounts became unavailable. Accounts hosted on this server experienced errors in contact-related features during this window. Accounts hosted on other servers were not affected. No data was lost.
What was affected
For impacted accounts only:
- Contact management — creating, updating and viewing contacts was unavailable.
- Transactional email — approximately 120,000 messages were delayed. They were queued, not dropped, and all were delivered once service was restored.
- Campaign statistics — open tracking was delayed, so open figures were temporarily stale and open webhooks arrived late.
- SMS delivery reports — status notifications were delayed.
- API — calls reading or writing contact data returned errors.
- Automations — workflow steps needing affected contact data failed during the window.
What happened
Several independent sources of elevated load reached the same database server simultaneously, including a recent software change that had made an internal contact-related operation significantly more resource-intensive. None of these would have caused an outage alone; combined, they exhausted the server's memory and it stopped responding. Its standby replicas were under the same pressure and automatic failover could not complete.
Timeline (UTC)
- 09:34 — Impact begins
- 10:25 — Incident declared, teams engaged
- 11:54 — First source of excess load stopped
- 12:12 — Root cause identified
- 13:26 — Database server fully restored
- 13:40 — All services confirmed normal; all queued messages and events delivered
Data integrity
No contact data was lost. Writes during the outage were rejected rather than silently discarded, and all queued messages and events were replayed and confirmed processed before the incident was closed.
What we are doing to prevent this
- Replacing the resource-intensive operation with an efficient alternative.
- Strengthening monitoring and alerting on database load so performance regressions are detected within hours, not days.
- Adding mandatory post-release performance verification for changes affecting shared database services.
- Increasing memory headroom on contact database servers so load spikes degrade gracefully instead of causing outages.
- Improving rate limiting to prevent excess traffic from reaching the database unthrottled.
- Reducing database server recovery time, the largest contributor to this incident's duration.
We sincerely apologize for this disruption and its impact on your business. If you have questions about how this incident affected your account, please contact our support team.