I just spent 2 hours trying to determine why no transactional emails were coming trough. Nothing in the live log, nothing in the log, two mails then come through, but once again - nothing in the logs, nothing in the API response indicating failure or any other brevo-side issue.
As a customer, the first place I will visit when there is a problem is the backend log pages, and sadly there is no indication that the entire brevo transactional back-end has been broken (and seemingly for quite some time)
I even looked at the console output from the app-smtp.brevo.com page and a large number of errors were shown in the log, but does not appear directly on the UI (another major issue - if the code fails, you really should tell the user that something is wrong instead of just showing an empty chart).
Up ! I can’t agree more.
You can still subscribe with your mail to https://status.brevo.com/ but I strongly agree that seeing it directly on Brevo is a must. Maybe in the « Transactional logs » ?
The real issue here is something else: a company that manages services of this kind should absolutely have well-tested failover systems and business continuity plans in place. The fact that a single « infrastructure component » was able to cause such a widespread outage points to an architectural weakness or a critical dependency with no redundancy.
For those using the platform for professional applications, this kind of prolonged downtime represents an excessive risk. On top of that, we haven’t received any direct communication about the incident. Personally, I wasted three hours trying to figure out what was going on.
This is not the end of it, of course—they will have to be held accountable in some way.