Date: August 26-27, 2026
Duration: 11 hours 38 minutes
Severity: Minor
We've been moving Buffer to a new login flow. The previous system never expired a session, so many long-time customers hadn't been asked to log in for months. On August 26, we widened the rollout of the new flow in several steps across the day. For the first time, many of those accounts had to log in again and pass the email verification step, and two weaknesses that had been sitting in that step all along became visible.
The first: verification codes expired after one minute. The login session waiting for the code could time out before anyone entered it, and Buffer then rejected the code as not matching even though it was correct.
The second: some verification emails never arrived at all. Our overall sending volume looked normal, and we found no problem with our email provider, so this was intermittent rather than a full outage. When a send fails, our code logs the error internally and tells you nothing, so you'd be left waiting for an email that may never have gone out. We haven't been able to pin down exactly where these emails were lost, and that part of the investigation is still open.
If you were affected, you were signed out of Buffer without warning, sometimes with a message that you'd logged in from another device. When you tried to log back in, one of two things happened. Either the verification email never arrived, even after you checked spam and requested a new one, or it did arrive, and Buffer rejected the code as not matching. Either way, you couldn't get into your account.
Being locked out of your account meant posts you'd planned to check, edit, or schedule had to wait, and we're sorry.
Our support team spotted a cluster of login and verification reports, declared an incident, and put up a status page. We started reaching out to the customers who'd written in.
Our first suspect was a change that limits how many login attempts can be made in a short time, which had shipped shortly before the reports began. We reverted it as a precaution. Our logs then showed it hadn't rejected a single login, and we reinstated it the next morning once we'd confirmed it played no part.
We lined the timing of the reports up against the rollout of the new login flow and they matched. We rolled the new flow back so that customer logins went through the previous flow again.
New reports stopped after the rollback. A customer who hadn't been receiving verification emails confirmed they could log in again, and we kept monitoring overnight without seeing the problem return.
The next morning we re-read every support report and sorted them into the two patterns above, which pointed to the two causes. We extended verification code validity from one minute to five minutes.
By the following morning there had been no confirmed new cases since the rollback, so we resolved the incident. The new login flow stayed off for customers while we finished the work above.
A verification window has to fit the slowest realistic path, not the fastest. We set it to one minute with a single person in mind and never tested it against a shared inbox. Codes now stay valid for five minutes.
A failed email should be visible, not quietly logged. Because our code caught send failures and only logged them, "the email never arrived" looked identical to "the customer hasn't checked yet" from our side. There was nothing on the login screen to tell you the send had failed, and nothing in our metrics to show us it was happening.
We found this through support tickets, more than four hours after it started. We had no alert on how often verification codes were rejected or how many verification emails failed to send. The first reports came in while the rollout was still small and were too few to stand out. The pattern only became clear as the rollout widened and more accounts hit the same wall.
