ProtonBlog(new window)

Incident report regarding the March 15th, 2018 technical issues

Share this page

Here is what happened, why it was not fixed sooner, and what we are doing to prevent this from ever happening again.

The incident began with a typo in a configuration relating to our anti-spam subsystem which was committed by the on-shift engineer as part of our routine anti-spam operations. Integration tests were performed but due to several circumstances did not detect the error. The broken patch was then deployed to our production servers on a rolling basis. Because the API was not returning the correct response, our load balancers successively dropped the production web servers one by one until all servers were dropped. As a result, Proton Mail users started receiving 503 errors.

This, fundamentally, is what brought down Proton Mail. From an engineering perspective, the obvious conclusion is that integration tests performed were clearly insufficient to detect the kind of error introduced, and we have adjusted our deployment procedure accordingly.

The second part of the story is why it took an hour to restore services. The reasons boil down to a combination of bad timing and monitoring issues. The bad timing was that it happened during the shift change (from night to day) which delayed the response. We have instituted new policies to prevent these kinds of deployments too close to the shift change.

The monitoring issues were also serious. No less than 3 monitoring systems should have immediately warned us that something was wrong, but none did. The first system monitors the availability of the site from an off-site location. Unfortunately, this system only monitored a subset of our domains, and those were not affected by the deployment. This system has now been updated to monitor all of our domains and subdomains.

The second monitoring system monitors changes in event rates to detect spikes and dips that should be brought to our attention. We can call this system the rate monitor. As much of the main API system was offline, the rate monitor should have notified us that event rates had flatlined. It did not, however, because it had been taken out of production earlier in the day for maintenance and had failed to come back up automatically. The monitoring for the rate monitor server itself also did not function properly because it had been disabled in advance of the maintenance work.

Finally, we have yet another system that monitors API error logs. However, the class of error that caused the downtime is logged to a specific error log which is normally empty, so we were not monitoring that at all. This has also now been corrected.

In summary, too many things went wrong simultaneously, and had any one of them detected a problem, this incident could have been avoided or quickly fixed. The fact that they did not detect the problem or did so too late is our mistake. We accept that responsibility and have taken the policy and engineering steps necessary to prevent this kind of incident from happening again. We know how important reliability is to our users, and while sometimes incidents are outside of our control(new window), this one was not, and we have learned from these mistakes to make Proton Mail even more reliable.

Protect your privacy with Proton
Create a free account

Share this page

Bart Butler(new window)

Bart is the CTO of Proton, the company behind Proton Mail and Proton VPN. An expert in email encryption, Bart was previously a physicist at CERN working on the ATLAS experiment. He was also a postdoctoral researcher at Harvard and received his PhD in Physics from Stanford University.

Related articles

What was your first pet’s name? In what city were you born?  We’ve all had to answer these questions to reset a long-forgotten password, but consider how that works. Much of this information is easy to find for others (or easily forgotten by you), m
In the early days when Proton started, we often received a question along the lines of “I love the product and what Proton stands for, but how do I know you will still be around to protect my data 10 years from now?”  Ten years and 100 million accou
Credential stuffing is a popular type of cyberattack where attackers take login credentials and use them on thousands of websites, hoping to fraudulently gain access to people’s accounts. It’s an effective attack, but fortunately, one that’s easy to
With Skiff abruptly shutting down operations, many people are on the lookout for alternatives that don’t compromise on privacy — and won’t suddenly disappear. People were attracted to Skiff because it promised privacy, no ads, end-to-end encryption,
Skiff is dead. On Feb. 9, the email company Skiff announced it was being bought by Notion. Many Skiff customers have been shocked by this news, as their inboxes have been sold out from under them. Skiff gave people six months to export their data be
Looking into the Dropbox privacy policy
Dropbox was the first mainstream cloud storage provider, and still the biggest player on the market, with 700 million users in 2022. We took a dive into Dropbox’s privacy policy to see how well the company protects the personal data of those millions