Proton users are once again reporting problems accessing Proton Mail and other Proton services, just days after the company suffered one of its most significant infrastructure outages in recent memory.

This time, Proton says the disruption is connected to residual hardware failures that are likely related to damage caused by last week’s overheating incident.

In an update posted on Proton’s status page on September 1, the company said it is operating at reduced capacity while engineers work to bring additional infrastructure online. Proton initially acknowledged that a small number of users were experiencing problems accessing its services and later updated the incident with details about the underlying hardware failures.

Proton Mail is experiencing another disruption

The latest incident is particularly notable because it comes only a few days after Proton’s August 27 global outage, which was ultimately traced to a catastrophic cooling failure at the company’s Frankfurt data center.

According to Proton’s latest status update, the company is now dealing with “residual hardware failures” that are likely related to damage sustained during that overheating event.

The September 1 status update says Proton is:

• Dealing with residual hardware failures
• Operating at reduced capacity
• Bringing additional infrastructure online
• Investigating access problems affecting a subset of users

The first status-page update for the new disruption was posted at 14:37 CEST on September 1, when Proton said it was investigating reports from a small number of users.

At 16:42 CEST, Proton provided the more significant explanation: the company said the remaining hardware failures were likely related to the damage from the previous week’s overheating incident.

This is not simply another unrelated Proton Mail outage occurring a few days after the previous one. Based on Proton’s own wording, the infrastructure damage from the August incident is still having consequences.

What is happening to Proton Mail today?

Proton’s current incident affects Proton services, rather than being explicitly limited to Proton Mail.

Users have reported problems with services including Mail, Pass, Drive and other parts of the Proton ecosystem.

Independent outage reports also show users experiencing login failures, service errors and inability to load Proton applications. Some users have reported that one Proton service works while another does not, which is consistent with a partial or capacity-related infrastructure problem rather than an absolute shutdown of every Proton system.

The official Proton status page currently lists Proton Mail and several other services as being under maintenance or experiencing degraded availability, while Proton’s separate incident entry describes the ongoing service disruption.

This means the experience can vary significantly between users.

One person may be able to open Proton Mail normally while another sees:

• Login failures
• “Something went wrong” errors
• Pages that fail to load
• Authentication failures
• Repeated redirects
• Very slow loading
• Proton Pass failures
• Proton Drive failures
• Calendar problems
• Missing or delayed notifications
• Requests being rejected or rate limited

Reports from users today have also described Proton Mail and Pass becoming inaccessible while other services remained partially usable.

Proton says the new problems are linked to last week’s overheating

This is the most important development.

Proton’s September 1 update says its engineers are currently dealing with residual hardware failures likely related to the damage suffered during the overheating incident last week.

The company says it is currently operating at reduced capacity while additional infrastructure is being brought online.

That provides an important link between the two incidents.

The August 27 outage was not simply a software bug or temporary networking problem. Proton’s postmortem revealed that its Frankfurt data center suffered a complete cooling-system failure, causing temperatures inside the facility to rise extraordinarily quickly.

The result was physical stress and failure of infrastructure.

Proton said some servers actually suffered heat death, while it was also uncertain whether the surviving hardware could experience shortened lifespans as a result of the incident.

Now, several days later, Proton is explicitly saying that residual hardware failures are likely related to that damage.

What happened during the August 27 Proton outage?

To understand today’s disruption, it is necessary to go back to the incident that started late on August 26 and continued into August 27.

Proton’s postmortem provides an unusually detailed explanation.

Shortly after 11:00 p.m. CEST on August 26, a cooling-system failure occurred in the main room of Proton’s Frankfurt data center.

At approximately 11:15 p.m. CEST, the temperature began climbing rapidly.

The normal temperature was approximately:

21.8°C

Within less than half an hour, the temperature reached approximately:

51.9°C

Some sensors reportedly recorded approximately:

60°C

inside the room.

That is an enormous temperature increase for a production data center.

As temperatures climbed, servers and networking equipment began failing one after another.

The cooling system failure became a hardware failure

This is where the August incident became much more serious than an ordinary data center outage.

Proton’s infrastructure is designed with redundancy and the company says it has enough capacity to survive the complete loss of a data center under normal failure scenarios.

But the Frankfurt incident created a more complicated situation.

Hardware wasn’t simply disappearing from the network.

It was failing progressively as the environment overheated.

That created a difficult recovery scenario.

According to Proton, a critical rack eventually lost both its primary and backup network switches.

Several primary database copies were located on that rack.

This was particularly significant because Proton does not automatically fail over primary databases without human supervision.

The reason is deliberate: automatically switching databases in certain circumstances can create a “split brain” scenario where multiple database copies diverge and become difficult to reconcile.

So Proton’s redundancy mechanisms did not simply mean:

Frankfurt fails → everything instantly moves elsewhere.

The reality was considerably more complicated.

Why didn’t Proton immediately fail everything over to another data center?

This is one of the most interesting technical aspects of the outage.

Proton had to make decisions while the physical infrastructure was actively overheating.

Its engineers effectively had to balance two competing priorities:

1. Restore services as quickly as possible.
2. Prevent even more physical infrastructure from being destroyed.

Proton says the rising temperatures forced the team to prioritize protecting the hardware and restoring cooling.

That decision potentially increased the duration of the outage, but losing substantially more hardware could have created an even larger and longer-term problem.

The company also had to decide whether to fail over to:

• Other infrastructure in Frankfurt
• Zurich
• Or perform a broader failover

The situation was complicated because failing over to hardware inside the same facility could potentially place services back onto infrastructure that was still at risk.

The temperature reached levels capable of disabling network hardware

One of the most striking details in Proton’s postmortem concerns the network cards.

Some network cards in the Frankfurt infrastructure reached approximately:

105°C

Their normal operating temperature was around:

45°C.

At that temperature, the network hardware entered a protection mode and became disabled until a cold system reset could be performed.

This created another recovery obstacle.

Proton’s security architecture limits access to out-of-band controllers, meaning engineers could not simply remotely reset everything in the usual manner.

Additional personnel had to be brought in to assist with recovery.

Proton eventually restored most services

By approximately 00:45 CEST on August 27, Proton said cooling had been restored and temperatures began falling.

The engineering team then shifted its focus toward service recovery.

By approximately 01:30 CEST, most services were back online for most users.

However, some less-critical components took longer.

Proton said services such as:

• Push notifications
• Payment processing

were not recovered until approximately 02:00 CEST.

And even that wasn’t the end of the incident.

The outage continued after Proton services came back online

Service availability returning did not mean the infrastructure had immediately returned to a normal state.

Proton said that after the initial recovery, its infrastructure was left in an abnormal configuration.

Some primary databases were in Zurich.

Others were in Frankfurt.

Some databases were operating with reduced redundancy.

Some were also operating with reduced performance.

The database team continued working through August 27 to restore full redundancy.

This is precisely why today’s September 1 incident is significant.

The infrastructure wasn’t simply repaired and forgotten.

The consequences of the physical failure continued after the initial outage.

Some servers were permanently damaged

Proton’s postmortem contains another critical detail.

The company said that although it managed to save almost all of its infrastructure, some servers suffered heat death.

It also said it did not yet know whether the overheating event would affect the lifespan of surviving equipment.

Now, several days later, Proton’s September 1 update says it is dealing with residual hardware failures that are likely connected to the damage caused by that overheating event.

That creates a plausible chain:

Cooling failure

↓

Extreme temperature rise

↓

Servers and networking equipment fail

↓

Critical redundancy is lost

↓

Emergency failover and recovery

↓

Some hardware suffers permanent damage

↓

Infrastructure operates in a reduced or abnormal configuration

↓

Additional hardware failures appear

↓

Proton operates at reduced capacity

↓

September 1 service disruption

This is not speculation about the cause of today’s incident. The link between today’s residual hardware failures and last week’s overheating was explicitly stated by Proton in its September 1 update.

What actually caused last week’s cooling failure?

Proton’s postmortem goes further.

The company said its investigation on August 27 traced the cooling failure to an air-filter replacement on both of the redundant air compressors powering the cooling system.

The particularly problematic part was that the work was carried out by the data center operator:

• In the middle of the night
• Without prior notice to Proton
• While both redundant air compressors were involved

Proton also said the operator failed to communicate the cooling failure when it occurred.

That significantly reduced the amount of time Proton had to respond.

In other words, the initial event was not caused by Proton intentionally taking its services offline.

It was a physical infrastructure failure involving the cooling system at the Frankfurt facility.

Why did the data center heat up so quickly?

Proton highlighted an interesting infrastructure trend.

Modern data centers have become substantially more power-dense, particularly as CPUs and GPUs have become more powerful and AI workloads have increased.

More power density means more heat that must be removed.

Proton said that what historically could have taken three to four hours to reach critical temperatures instead became critical in approximately 20 minutes during this incident.

That dramatically changes the amount of time available for intervention.

A cooling failure that previously might have allowed operators several hours to diagnose the problem, shut down systems and transfer workloads can become an emergency within minutes.

August 27 Proton outage timeline

Here is the reconstructed timeline based on Proton’s official incident history and postmortem.

Time	Event
Aug. 26, shortly after 23:00 CEST	Cooling system failure occurs in Proton’s Frankfurt data center
~23:15 CEST	Data center temperatures begin rapidly increasing
~23:15-23:45 CEST	Temperatures rise from approximately 21.8°C to 51.9°C, with some sensors reaching around 60°C
~00:00 CEST, Aug. 27	User-facing failures begin escalating as critical redundancy is lost
00:11 CEST	Proton officially begins investigating the outage
00:18 CEST	Proton says some VPN functionality remains available and changes VPN impact to partial outage
00:38 CEST	Proton identifies the critical cooling failure in Frankfurt and begins shifting traffic
00:45 CEST	Cooling is restored and temperatures begin dropping
~01:30 CEST	Most services return for most users
~02:00 CEST	Push notifications and payment processing recover
02:27 CEST	Proton reports that a fix has been implemented and begins monitoring recovery
Aug. 27 onward	Engineers work to restore database redundancy and normalize infrastructure
Aug. 29	Proton reports that remaining minor issues have been resolved
Aug. 28	Proton publishes its detailed postmortem
Sep. 1	Proton reports a new service disruption and residual hardware failures likely connected to the overheating incident

The official status history confirms the August 27 incident, including the progression from investigation to identification of the Frankfurt cooling failure, recovery and eventual resolution.

September 1 Proton outage timeline

The new incident is still developing.

Based on Proton’s status updates and the screenshot provided, the timeline currently looks like this:

Time	Event
Sep. 1, 14:37 CEST	Proton says a small number of users may be experiencing problems accessing Proton services
Sep. 1, 14:37 CEST onward	Engineers investigate the disruption
Sep. 1, 16:42 CEST	Proton says it is dealing with residual hardware failures likely related to damage from last week’s overheating
Sep. 1, 16:42 CEST	Proton confirms services are operating at reduced capacity
Sep. 1, 19:10 CEST	Database capacity is being restored. Traffic limitations are being gradually lifted, and outgoing mail will be re-enabled as soon as the situation is stable
Sep. 1, 19:26 CEST	Traffic limitations have been fully removed for all users. Outgoing emails to be gradually re-enabled within the next hour

The September 1 update is particularly important because it moves the explanation beyond a generic “service disruption.”

Proton is acknowledging that the company is currently dealing with hardware-level consequences from the previous incident.

Is Proton Mail completely down?

No, not universally.

The evidence currently points to a partial disruption rather than every Proton Mail account becoming completely inaccessible.

Proton itself described the affected population initially as a “small number of users.” At the same time, user reports indicate that the impact is broader than a single isolated account or device.

Some users have reported:

• Proton Mail unavailable
• Proton Pass unavailable
• Proton Drive unavailable
• Authentication failures
• Login problems
• “Something went wrong” errors
• Intermittent access
• Services working on one device but not another

Independent monitoring also shows reports involving several Proton products.

This is consistent with Proton’s statement that it is operating at reduced capacity.

Has Proton lost emails?

For the August 27 incident, Proton explicitly said that no emails were lost, although email delivery in both directions was delayed during the incident.

For the September 1 incident, users should not assume that today’s disruption means messages have been lost.

At the time of this update, Proton’s latest statement focuses on residual hardware failures and reduced capacity. It does not announce an email-data-loss event.

Service availability problems do not automatically mean data loss.

Email may be delayed, queued or temporarily inaccessible without being permanently deleted.

Why today’s outage matters more than a normal Proton Mail outage

A short-lived service outage is one thing.

A second disruption shortly after a major physical infrastructure failure is another.

The significance of today’s event comes from the sequence.

Last week’s incident caused:

• Extreme overheating
• Network hardware failures
• Database redundancy loss
• Emergency failover operations
• Physical server damage
• Reduced infrastructure redundancy
• Abnormal database placement
• Extended recovery work

And Proton has now acknowledged that some residual hardware failures are likely related to that event.

That means the August 27 incident should be viewed less like a single isolated outage and more like a multi-stage infrastructure recovery event.

The initial service outage ended.

The infrastructure recovery did not.

Proton was already planning additional resilience work

The August outage also exposed limitations in Proton’s existing infrastructure.

Proton said database resilience work designed to address this particular failure mode was already underway and was planned for completion by the end of 2026.

The company also said additional infrastructure capacity, including new data center space, was being commissioned and was expected to become available within the following weeks.

The objective is to reduce dependence on a single physical site and make unusual failure scenarios less disruptive.

That work is especially relevant now because today’s outage demonstrates exactly why redundancy isn’t simply a checkbox.

Having multiple copies of data or multiple sites does not guarantee instant recovery from every possible failure.

The way systems fail matters.

Redundancy isn’t the same as instant recovery

One of the biggest technical lessons from the Proton outage is that redundancy has layers.

You can have:

• Multiple servers
• Multiple network switches
• Database replicas
• Multiple data centers
• Backup systems
• Traffic failover
• Disaster recovery procedures

And still experience an outage.

Why?

Because the failure may happen across several layers simultaneously.

In Proton’s case, the problem wasn’t simply:

One server died.

The incident involved a cooling failure that caused many pieces of equipment to start failing in succession.

That meant some of the supposedly redundant components were being damaged by the same physical condition.

This is a classic infrastructure lesson:

Two systems are not truly independent if the same physical failure can take both of them down.

The hidden danger of correlated failures

Suppose a data center has:

Network switch A

and

Network switch B

If switch A fails because of a firmware bug, switch B might continue operating.

But if both switches are sitting in the same overheated rack, a cooling failure can potentially affect both.

The redundancy exists logically, but the physical failure domain is shared.

That is effectively what made the Frankfurt event so difficult.

The same environmental condition was capable of damaging multiple layers of infrastructure.

This is why modern resilient infrastructure attempts to separate failure domains across:

• Racks
• Power systems
• Cooling systems
• Network paths
• Availability zones
• Buildings
• Data centers
• Geographic regions

Proton’s postmortem indicates that its ongoing resilience work is intended to reduce exposure to precisely these kinds of failure scenarios.

Why Proton’s reduced capacity matters

Proton’s latest update says it is operating at reduced capacity while engineers bring additional infrastructure online.

That is a meaningful technical statement.

It suggests Proton isn’t simply waiting for a software fix.

Instead, the company is working through an infrastructure availability problem.

Reduced capacity can manifest itself in several ways depending on which systems are constrained:

• Higher latency
• Authentication failures
• Intermittent service availability
• Increased error rates
• Slower synchronization
• Delayed notifications
• Temporary rate limiting
• Failed requests
• Certain users being affected while others are not

This could also explain why two users can have very different experiences during the same incident.

One account may work normally while another encounters errors.

Why some users may still be able to use Proton

A partial outage can depend on several factors.

For example:

• Which infrastructure handles the user’s request
• Which service is being accessed
• Whether the account needs a particular backend
• Whether a database replica is available
• Which authentication path is being used
• Regional traffic routing
• Cached or locally available data

This means:

“Proton works for me” does not necessarily mean Proton is fully operational.

Likewise:

“Proton is down for me” does not necessarily mean every Proton user is affected.

The current status language from Proton is consistent with a partial and evolving incident.

What Proton users should do right now

If Proton Mail isn’t loading, repeatedly refreshing the page is unlikely to fix an underlying infrastructure problem.

Instead:

1. Check Proton’s official status page

Check Proton’s live service status

This is the most authoritative source for Proton’s own incident updates.

2. Don’t immediately reset your password

If the problem is an authentication or backend outage, changing your password will not fix the infrastructure problem and can create additional confusion.

3. Try another Proton client

If the web application isn’t working, you can check whether the mobile application or desktop application behaves differently.

However, different behavior does not necessarily mean the issue is local to your device.

4. Don’t repeatedly hammer the login endpoint

Repeated login attempts can make troubleshooting harder and may trigger rate limiting.

5. Check again after Proton posts an update

The current incident is actively being investigated.

The status can change rapidly as additional infrastructure is brought online.

What happens to incoming emails while Proton Mail is unavailable?

A temporary inability to access the mailbox is not necessarily equivalent to losing incoming mail.

Email systems can queue messages when the recipient’s server is temporarily unavailable.

During the August outage, Proton explicitly stated that email was not lost, although delivery in both directions was delayed.

For today’s incident, users should wait for Proton’s final incident report before drawing conclusions about delivery behavior.

If you are expecting an important message, the safest assumption is that delivery may be delayed until Proton confirms normal operation.

Proton’s August outage was already unusual. Today’s follow-up makes it more significant

The August 27 incident was unusual because a cooling failure escalated into a major infrastructure event within minutes.

The chain looked roughly like this:

Cooling system failure

→ Rapid temperature increase

→ Servers begin failing

→ Network redundancy lost

→ Database redundancy affected

→ Emergency traffic shifting

→ Hardware protection mechanisms triggered

→ Manual intervention required

→ Services restored

→ Infrastructure left in reduced/abnormal state

→ Physical hardware damage discovered

Now:

Residual hardware failures

→ Reduced Proton capacity

→ September 1 service disruption

This is why today’s Proton Mail outage deserves attention even if the number of affected users is smaller than last week’s global outage.

What Proton has said about preventing another major outage

Proton’s August postmortem says it is working with the data center operator to prevent a repeat of the cooling incident.

The company is also working on database resilience and commissioning additional infrastructure.

Proton acknowledged that the combination of circumstances that caused the original outage was highly unusual, but also recognized that unusual failure scenarios can and do happen.

The company therefore says it is reviewing where resilience improvements can safely be accelerated.

That is particularly relevant now because the September 1 disruption demonstrates that the physical consequences of an infrastructure incident can persist well after the initial outage has been resolved.

Is Proton Mail down right now?

Proton is currently experiencing a service disruption affecting some users.

Proton’s official status page has acknowledged the incident.

The company says it is dealing with residual hardware failures likely related to damage from last week’s overheating event and is operating at reduced capacity while bringing additional infrastructure online.

The situation is therefore ongoing and evolving rather than a simple historical outage.

Bottom line

The September 1 Proton Mail disruption is significant because it appears to be connected to the aftermath of the much larger August 27 infrastructure failure.

Last week, Proton’s Frankfurt data center experienced a catastrophic cooling failure. Temperatures climbed from approximately 21.8°C to more than 50°C in less than half an hour, with some sensors reporting around 60°C. Servers and network equipment began failing, database redundancy was disrupted, and some hardware ultimately suffered heat damage.

Proton managed to restore services and said no emails were lost, although delivery was delayed.

But the recovery did not end there.

Some hardware had been damaged, some infrastructure remained in an abnormal state, and Proton continued rebuilding redundancy.

Now, on September 1, Proton says it is dealing with residual hardware failures likely related to that overheating incident, while operating at reduced capacity and bringing additional infrastructure online.

That makes today’s outage more than another isolated “Proton Mail is down” event.

It is a reminder that a major physical infrastructure failure can continue to produce secondary failures days after the original outage appears to be resolved.

For Proton users, the key takeaway is that there is currently no indication from the company that today’s disruption represents a breach or loss of encrypted email data. The available evidence points toward an infrastructure recovery problem following last week’s severe Frankfurt data center incident.

And importantly, the incident is still developing.

Proton’s own status updates should be treated as the authoritative source for further recovery announcements.

Official Proton postmortem

Proton has published a detailed technical explanation of the August 27 incident, including the cooling failure, temperature rise, hardware failures, database failover decisions, recovery process and planned resilience improvements.

Read Proton’s full August 27 outage postmortem

Editor’s note: This article should be updated as Proton publishes additional September 1 incident updates. The September 1 outage is ongoing, so claims about its final duration, full scope, root cause beyond the currently stated hardware failures, and final data impact should not be treated as settled until Proton closes the incident.