Zaptec Status

Postmortem: On October 2, 2026, Zaptec identified an issue affecting a subset of OCPP Cloud chargers. The issue caused delays in message processing between cloud services, which led to some charging sessions stopping shortly after they began. The incident primarily affected customers using OCPP Cloud integrations. The issue was investigated by the on-call engineering team and was resolved once cloud message-processing latency returned to normal.

## Customer Impact
Some customers experienced interrupted charging sessions for OCPP Cloud chargers.
The main symptoms were

• Charging sessions started from an app stopped shortly after beginning.
• Some sessions ended after delivering little or no energy.
• Affected sessions were not able to continue normally once the backend transaction response was rejected.

Based on the initial customer report, the issue may have affected a significant number of sessions from October 1 to October 2, 2026.

## Timeline

• October 2, 2026, 19:46: Support escalated a customer-reported issue involving OCPP Cloud chargers.
• October 2, 2026, 20:03: The on-call engineer began investigating the issue.
• October 2, 2026, 20:09: Monitoring showed increased delay in message handling between cloud services. This indicated that the issue was likely related to delayed processing rather than charger behavior.
• October 2, 2026, 20:15: Further investigation confirmed unusually high message-processing latency in one of the cloud messaging components. This caused downstream services to process charging events more slowly than normal.
• October 2, 2026, 20:20: Support was informed that a customer-facing status update should be prepared, communicating that Zaptec was experiencing delays in message processing due to cloud infrastructure issues.
• October 2, 2026, 20:22: The engineering team agreed to attempt a mitigation by resizing the affected messaging component in order to move processing to healthier infrastructure.
• October 2, 2026, 20:24: The mitigation was performed, but it did not immediately improve the situation.
• October 2, 2026, 20:26: The on-call engineer began escalating the issue through the cloud infrastructure support path.
• October 2, 2026, 20:48: Message-processing latency returned to normal, and charging-related messages were again being processed as expected.
• October 2, 2026, 21:13: The cloud support partner confirmed that a ticket was being created for further investigation by the underlying cloud provider.

## Root Cause Analysis
The issue was caused by elevated latency in a cloud message-processing component used by Zaptec's backend services.

This delay affected the flow of charging-session messages between systems. As a result, transaction-related messages were not processed within the expected time window. For affected OCPP Cloud sessions, this could cause the backend response to arrive too late or result in the transaction being rejected, after which the charger stopped the session.

The investigation found no indication that the chargers themselves were behaving incorrectly. The chargers followed the expected behavior after receiving a response that the transaction was not accepted.

The issue was also not caused by general database saturation or a broad platform outage. The impact was isolated to the delayed message-processing path used by the affected charging-session flow.

## Resolution
The incident was resolved when the delayed cloud message-processing returned to normal operation at approximately 20:48 on October 2, 2026. An attempted infrastructure resize did not have an immediate observable effect. The issue normalized shortly afterward, and the support path with the cloud infrastructure provider was used to request further investigation.

## Current Status
The affected message-processing path is currently operating normally.

Zaptec has requested further investigation from the relevant infrastructure support channels to determine why the latency increased and whether additional preventive measures are needed.

## Follow-Up Actions
Zaptec will take the following actions:

• Add improved alerting for message-processing latency to reduce time to detection and root-cause analysis.
• Review the affected OCPP Cloud message-processing flow to reduce dependency on components that may introduce significant delays.
• Prioritize architectural improvements to reduce the risk of similar disruptions.

Resolved: This incident has been resolved.

Monitoring: A fix has been implemented and we are monitoring the results.

Investigating: We’re currently experiencing delay in the message processing due to the cloud provider issues

Postmortem: ## Incident summary

On September 24, 2026, we identified a delay in one of our telemetry-processing services. The service was receiving data faster than it could process it, which created a growing backlog.
Core charging functionality and primary communication services continued to operate normally. However, delayed telemetry processing affected the responsiveness of the Solar feature for some APM devices.

The backlog was fully processed by October 1, 2026, and the incident was subsequently resolved.

Customer impact

The incident had a limited impact on customers:

• Core charging operations remained available.
• Primary device communication services were not affected.
• The Solar feature for some APM devices experienced delays because it depends on timely telemetry data.
• No permanent loss of service was identified.

Incident timeline

September 24, 13:13 — Monitoring detected a growing difference between the amount of telemetry received and the amount processed. The team began investigating and initiated incident communications.
September 24, 15:06 — An internal incident was declared. The service appeared healthy according to the available monitoring, but its processing capacity was insufficient to keep up with incoming data.
September 24, 15:19 — The team identified oversized telemetry records that could cause groups of messages to be processed repeatedly. A change was deployed to isolate and discard invalid records rather than retrying the entire group.
September 24, 15:22 — The change improved resilience but did not resolve the processing delay. The investigation found that the service's limited monitoring made it difficult to identify the main performance constraint.
September 24, 15:57 — Further analysis indicated that the issue was within the application's processing method rather than the underlying data-storage service.
September 24, 17:12 — An updated version of the service was prepared for testing. Because core services remained operational, the team prioritized careful validation over an immediate production deployment to avoid introducing additional risk.
September 24, 21:41 — The updated service was running successfully in the development environment. Testing continued to confirm that all processing scenarios worked as expected.
September 30, 17:01 — The updated service was deployed to production. Processing performance improved immediately, and the telemetry backlog began decreasing.
October 1, 00:30 — The telemetry backlog was fully processed.
October 1, 08:30 — The incident was declared resolved.

Root cause

The affected service processed data-storage operations one at a time. As the volume of telemetry increased, this sequential approach could no longer provide sufficient throughput, causing the backlog to grow.
The service was also based on an older application design with limited performance monitoring. This made the underlying bottleneck difficult to identify and extended the investigation.
Oversized telemetry records contributed to unnecessary reprocessing but were not the primary cause of the incident.

Resolution

We replaced the affected service with an updated version that can safely process multiple storage operations concurrently. This substantially increased processing capacity and allowed the service to clear the backlog.
We also improved the handling of oversized records so that a single invalid record no longer causes a larger group of telemetry messages to be reprocessed.

Preventive actions

To reduce the likelihood and duration of similar incidents, we have:
Modernized the affected service and aligned it with our current application standards.
Added improved monitoring for service health, processing performance, and backlog growth.
Introduced controlled parallel processing to support higher telemetry volumes.
Improved the handling of oversized or invalid telemetry records.
Begun reviewing the wider telemetry-processing architecture to simplify data flows and make service dependencies and customer impact easier to identify.
This was the final application using the relevant legacy architecture. Its modernization removes a significant source of technical debt and improves our ability to detect, diagnose, and resolve future performance issues.

Resolved: This incident has been resolved.

Monitoring: We are continuing to monitor for any further issues.

Monitoring: A fix has been implemented and we are monitoring the results.

Investigating: We are continuing to investigate this issue.

Investigating: We are continuing to investigate this issue.

Investigating: We are still investigating the root cause, from what we see charging in Zaptec mode should not be affected, but OCPP bridge could be.

Investigating: We're declaring incident. Cloud functions, but there might be some issues due to delayed processing. We will give updates around every hour.

Investigating: We are currently working on improving cloud stability. This is an unscheduled maintenance.

During this time, some users may experience delays in device status updates.

Device operation is not expected to be affected, but the displayed status may take longer than usual to refresh.

We apologise for the inconvenience and will provide an update when the situation has improved.

Postmortem: On October 2, 2026, Zaptec identified an issue affecting a subset of OCPP Cloud chargers. The issue caused delays in message processing between cloud services, which led to some charging sessions stopping shortly after they began. The incident primarily affected customers using OCPP Cloud integrations. The issue was investigated by the on-call engineering team and was resolved once cloud message-processing latency returned to normal.

## Customer Impact
Some customers experienced interrupted charging sessions for OCPP Cloud chargers.
The main symptoms were

• Charging sessions started from an app stopped shortly after beginning.
• Some sessions ended after delivering little or no energy.
• Affected sessions were not able to continue normally once the backend transaction response was rejected.

Based on the initial customer report, the issue may have affected a significant number of sessions from October 1 to October 2, 2026.

## Timeline

• October 2, 2026, 19:46: Support escalated a customer-reported issue involving OCPP Cloud chargers.
• October 2, 2026, 20:03: The on-call engineer began investigating the issue.
• October 2, 2026, 20:09: Monitoring showed increased delay in message handling between cloud services. This indicated that the issue was likely related to delayed processing rather than charger behavior.
• October 2, 2026, 20:15: Further investigation confirmed unusually high message-processing latency in one of the cloud messaging components. This caused downstream services to process charging events more slowly than normal.
• October 2, 2026, 20:20: Support was informed that a customer-facing status update should be prepared, communicating that Zaptec was experiencing delays in message processing due to cloud infrastructure issues.
• October 2, 2026, 20:22: The engineering team agreed to attempt a mitigation by resizing the affected messaging component in order to move processing to healthier infrastructure.
• October 2, 2026, 20:24: The mitigation was performed, but it did not immediately improve the situation.
• October 2, 2026, 20:26: The on-call engineer began escalating the issue through the cloud infrastructure support path.
• October 2, 2026, 20:48: Message-processing latency returned to normal, and charging-related messages were again being processed as expected.
• October 2, 2026, 21:13: The cloud support partner confirmed that a ticket was being created for further investigation by the underlying cloud provider.

## Root Cause Analysis
The issue was caused by elevated latency in a cloud message-processing component used by Zaptec's backend services.

This delay affected the flow of charging-session messages between systems. As a result, transaction-related messages were not processed within the expected time window. For affected OCPP Cloud sessions, this could cause the backend response to arrive too late or result in the transaction being rejected, after which the charger stopped the session.

The investigation found no indication that the chargers themselves were behaving incorrectly. The chargers followed the expected behavior after receiving a response that the transaction was not accepted.

The issue was also not caused by general database saturation or a broad platform outage. The impact was isolated to the delayed message-processing path used by the affected charging-session flow.

## Resolution
The incident was resolved when the delayed cloud message-processing returned to normal operation at approximately 20:48 on October 2, 2026. An attempted infrastructure resize did not have an immediate observable effect. The issue normalized shortly afterward, and the support path with the cloud infrastructure provider was used to request further investigation.

## Current Status
The affected message-processing path is currently operating normally.

Zaptec has requested further investigation from the relevant infrastructure support channels to determine why the latency increased and whether additional preventive measures are needed.

## Follow-Up Actions
Zaptec will take the following actions:

• Add improved alerting for message-processing latency to reduce time to detection and root-cause analysis.
• Review the affected OCPP Cloud message-processing flow to reduce dependency on components that may introduce significant delays.
• Prioritize architectural improvements to reduce the risk of similar disruptions.

Resolved: This incident has been resolved.

Monitoring: A fix has been implemented and we are monitoring the results.

Investigating: We’re currently experiencing delay in the message processing due to the cloud provider issues

Postmortem: ## Incident summary

On September 24, 2026, we identified a delay in one of our telemetry-processing services. The service was receiving data faster than it could process it, which created a growing backlog.
Core charging functionality and primary communication services continued to operate normally. However, delayed telemetry processing affected the responsiveness of the Solar feature for some APM devices.

The backlog was fully processed by October 1, 2026, and the incident was subsequently resolved.

Customer impact

The incident had a limited impact on customers:

• Core charging operations remained available.
• Primary device communication services were not affected.
• The Solar feature for some APM devices experienced delays because it depends on timely telemetry data.
• No permanent loss of service was identified.

Incident timeline

September 24, 13:13 — Monitoring detected a growing difference between the amount of telemetry received and the amount processed. The team began investigating and initiated incident communications.
September 24, 15:06 — An internal incident was declared. The service appeared healthy according to the available monitoring, but its processing capacity was insufficient to keep up with incoming data.
September 24, 15:19 — The team identified oversized telemetry records that could cause groups of messages to be processed repeatedly. A change was deployed to isolate and discard invalid records rather than retrying the entire group.
September 24, 15:22 — The change improved resilience but did not resolve the processing delay. The investigation found that the service's limited monitoring made it difficult to identify the main performance constraint.
September 24, 15:57 — Further analysis indicated that the issue was within the application's processing method rather than the underlying data-storage service.
September 24, 17:12 — An updated version of the service was prepared for testing. Because core services remained operational, the team prioritized careful validation over an immediate production deployment to avoid introducing additional risk.
September 24, 21:41 — The updated service was running successfully in the development environment. Testing continued to confirm that all processing scenarios worked as expected.
September 30, 17:01 — The updated service was deployed to production. Processing performance improved immediately, and the telemetry backlog began decreasing.
October 1, 00:30 — The telemetry backlog was fully processed.
October 1, 08:30 — The incident was declared resolved.

Root cause

The affected service processed data-storage operations one at a time. As the volume of telemetry increased, this sequential approach could no longer provide sufficient throughput, causing the backlog to grow.
The service was also based on an older application design with limited performance monitoring. This made the underlying bottleneck difficult to identify and extended the investigation.
Oversized telemetry records contributed to unnecessary reprocessing but were not the primary cause of the incident.

Resolution

We replaced the affected service with an updated version that can safely process multiple storage operations concurrently. This substantially increased processing capacity and allowed the service to clear the backlog.
We also improved the handling of oversized records so that a single invalid record no longer causes a larger group of telemetry messages to be reprocessed.

Preventive actions

To reduce the likelihood and duration of similar incidents, we have:
Modernized the affected service and aligned it with our current application standards.
Added improved monitoring for service health, processing performance, and backlog growth.
Introduced controlled parallel processing to support higher telemetry volumes.
Improved the handling of oversized or invalid telemetry records.
Begun reviewing the wider telemetry-processing architecture to simplify data flows and make service dependencies and customer impact easier to identify.
This was the final application using the relevant legacy architecture. Its modernization removes a significant source of technical debt and improves our ability to detect, diagnose, and resolve future performance issues.

Resolved: This incident has been resolved.

Monitoring: We are continuing to monitor for any further issues.

Monitoring: A fix has been implemented and we are monitoring the results.

Investigating: We are continuing to investigate this issue.

Investigating: We are continuing to investigate this issue.

Investigating: We are still investigating the root cause, from what we see charging in Zaptec mode should not be affected, but OCPP bridge could be.

Investigating: We're declaring incident. Cloud functions, but there might be some issues due to delayed processing. We will give updates around every hour.

Investigating: We are currently working on improving cloud stability. This is an unscheduled maintenance.

During this time, some users may experience delays in device status updates.

Device operation is not expected to be affected, but the displayed status may take longer than usual to refresh.

We apologise for the inconvenience and will provide an update when the situation has improved.

Resolved: This incident has been resolved.

Monitoring: A fix has been implemented and we are monitoring the results.

Identified: The issue has been identified and a fix is being implemented.

Investigating: Loading charger settings may take some time. We are currently investigating this issue.

Postmortem: On October 1, 2026, an internal shared service became unavailable to several dependent applications. This affected multiple API endpoints and reduced availability of the charger page in the customer portal.
The incident primarily impacted users trying to access charger-related information through the portal. The issue was mitigated by restoring the affected service and deploying an additional safeguard to prevent dependent applications from waiting indefinitely on slow service responses.

## Impact

• Several API endpoints experienced degraded availability or timeouts.
• The charger page in the customer portal was unavailable or intermittently failing for affected users during the incident.
• No data loss has been identified as part of this incident.

## Timeline

All times are in CEST on October 1, 2026.

• 15:21: Support reported slowness in the portal.
• 15:24: Engineers identified that one of the APIs was experiencing timeouts when calling an internal shared service.
• 16:00: The affected API was rolled back to the previous version to restore access to a previous fallback mechanism.
• 17:05: The fallback mechanism was enabled, but the charger page continued to fail.
• 18:35: Engineers identified that another API was calling the same internal shared service without a timeout.
• 18:51: The affected internal service instance was restarted, after which the charger page started working again.
• 19:00: A production fix was deployed to add a timeout for requests from the portal API to the internal shared service.

## Root Cause

The immediate cause of the incident was that dependent APIs were affected by slow or unavailable responses from a shared internal service.
The underlying cause of the service instability is still under investigation. During the incident, service health metrics showed significantly elevated memory-management activity, which indicates that the service was under heavy load at the time.
The affected shared service currently handles both resource-intensive background processing and real-time request serving in the same runtime environment. This makes it vulnerable to resource contention. When heavy processing occurs, real-time requests can be delayed or fail, which can then affect applications that depend on the service.

## Resolution

The incident was mitigated in two steps.
First, engineers rolled back one affected API to a previous version that still supported a fallback mechanism.
Second, the affected shared service instance was restarted, which restored functionality for the charger page.
A production fix was then deployed to add a timeout to one of the dependent APIs. This reduces the risk of the portal becoming unavailable when the shared service is slow or unresponsive.

## Current Status

The charger page functionality was restored on October 1, 2026 at approximately 18:51 CEST. A production fix was deployed at 19:00 CEST to reduce the risk of similar cascading failures.
Further investigation is ongoing to determine the exact cause of the shared service instability and to define longer-term architectural improvements.

Resolved: This incident has been resolved.

Monitoring: A fix has been implemented and we are monitoring the results.

Identified: The issue has been identified and a fix is being implemented.

Investigating: Charger settings in the Zaptec Portal are not responding. We are continuing to investigate the issue.

Investigating: Charger settings in the Zaptec Portal are not responding. We are continuing to investigate the issue.

Investigating: Loading charger settings may take some time. We are currently investigating this issue.

Resolved: This incident has been resolved.

Monitoring: A fix has been implemented and we are monitoring the results.

Identified: The issue has been identified and a fix is being implemented.

Investigating: We are continuing to investigate this issue.

Investigating: We are currently unable to receive phone calls to our Support department.

We are investigating the issue and will provide updates as soon as more information is available.

In the meantime, you can still contact us by email via our form https://www.zaptec.com/company/contact#hubspot-items We also have documents and self-help at our knowledge base https://help.zaptec.com/

You can also follow updates on our phone service provider’s status page: https://www.atender.com/status