Zaptec Outage History

Started Oct 15, 2026, 08:41 PM UTC· resolved Oct 19, 2026, 06:18 AM UTC

1. investigating Oct 15, 2026, 08:41 PM UTC

   We are investigating increased latency affecting communication between chargers and Zaptec Cloud Services. You may experience that live updates in both Zaptec Portal and App is not working as intended.

2. investigating Oct 15, 2026, 09:21 PM UTC

   We have made changes to help keep services running as smoothly as possible overnight while we continue investigating increased latency affecting charger communication with Zaptec Cloud Services. At this time, live updates in Zaptec Portal and the Zaptec App may still be delayed or not work as intended. Charging behavior itself is expected to remain unaffected. We are sorry for the inconvenience this may cause. We will continue the investigation tomorrow morning and provide a further update then.

3. investigating Oct 16, 2026, 06:00 AM UTC

   We are continuing to investigate this issue.

4. monitoring Oct 16, 2026, 10:08 AM UTC

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

5. resolved Oct 19, 2026, 06:18 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Oct 13, 2026, 08:00 PM UTC· resolved Oct 13, 2026, 11:55 PM UTC

1. resolved Oct 14, 2026, 09:16 AM UTC

   **Status:** Resolved **Duration:** 13 October 2026, 20:00 – 23:55 UTC (22:00 – 01:55 CEST) **Affected:** Zaptec chargers connected to a third-party charging operator or app (via OCPP) ## What happened On the evening of 13 October, a delay in Zaptec Cloud caused session-start messages to reach third-party charging operators 10–15 minutes late. Many operators rejected these late messages, and the affected charging sessions were stopped shortly after they began. Chargers managed only through the Zaptec app and portal could still charge. During the same period, live charger status in the Zaptec app and portal may have been delayed or outdated. ## Current status The issue is resolved. Service returned to normal at 23:55 UTC, and no action is needed from customers. If a charging session was stopped during the incident, starting a new session will work as usual. ## What we are doing We are working with our cloud provider to confirm the root cause. To prevent this from happening again, we are: - Adding monitoring to detect delays like this sooner We apologise for the disruption and for not updating this page during the incident. A further update will be posted when the investigation is complete.

Read the full incident report →

Started Oct 13, 2026, 02:00 PM UTC· resolved Oct 16, 2026, 10:00 AM UTC

1. identified Oct 13, 2026, 02:00 PM UTC

   Some users may currently experience incomplete or changed charging history in the app under Account / Charging history following recent backend improvements. This may affect Zaptec Pro users in shared installations who have access to a charger, but not to the full installation. In some cases, charging history may currently only be available through the Portal. We are reviewing this behavior and working to improve the experience in the app.

2. resolved Oct 16, 2026, 10:00 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Oct 02, 2026, 06:33 PM UTC· resolved Oct 03, 2026, 06:21 AM UTC

1. investigating Oct 02, 2026, 06:33 PM UTC

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

2. monitoring Oct 02, 2026, 07:03 PM UTC

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

3. resolved Oct 03, 2026, 06:21 AM UTC

   This incident has been resolved.

4. postmortem Oct 03, 2026, 06:22 AM UTC

   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.

Read the full incident report →

Started Oct 02, 2026, 06:01 AM UTC· resolved Oct 02, 2026, 07:56 AM UTC

1. investigating Oct 02, 2026, 06:01 AM UTC

   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/

2. investigating Oct 02, 2026, 06:28 AM UTC

   We are continuing to investigate this issue.

3. identified Oct 02, 2026, 07:50 AM UTC

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

4. monitoring Oct 02, 2026, 07:51 AM UTC

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

5. resolved Oct 02, 2026, 07:56 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Oct 01, 2026, 02:42 PM UTC· resolved Oct 02, 2026, 05:04 AM UTC

1. investigating Oct 01, 2026, 02:42 PM UTC

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

2. investigating Oct 01, 2026, 03:53 PM UTC

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

3. investigating Oct 01, 2026, 04:37 PM UTC

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

4. identified Oct 01, 2026, 04:55 PM UTC

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

5. monitoring Oct 01, 2026, 05:01 PM UTC

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

6. resolved Oct 02, 2026, 05:04 AM UTC

   This incident has been resolved.

7. postmortem Oct 02, 2026, 09:00 AM UTC

   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.

Read the full incident report →

Started Sep 24, 2026, 11:26 AM UTC· resolved Oct 01, 2026, 07:15 AM UTC

1. investigating Sep 24, 2026, 11:26 AM UTC

   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.

2. investigating Sep 24, 2026, 01:12 PM UTC

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

3. investigating Sep 24, 2026, 02:20 PM UTC

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

4. investigating Sep 24, 2026, 03:33 PM UTC

   We are continuing to investigate this issue.

5. investigating Sep 24, 2026, 04:43 PM UTC

   We are continuing to investigate this issue.

6. monitoring Sep 24, 2026, 06:35 PM UTC

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

7. monitoring Sep 25, 2026, 07:13 AM UTC

   We are continuing to monitor for any further issues.

8. resolved Oct 01, 2026, 07:15 AM UTC

   This incident has been resolved.

9. postmortem Oct 01, 2026, 11:07 AM UTC

   ## 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.

Read the full incident report →

Started Sep 11, 2026, 10:04 AM UTC· resolved Sep 11, 2026, 11:18 AM UTC

1. investigating Sep 11, 2026, 10:04 AM UTC

   We are currently experiencing issues in Zaptec Portal where changing electrical settings under Power Management may not work as expected. Some logs may also fail to load. Our team is investigating and working on a resolution. We apologise for the inconvenience and will provide updates as soon as we have more information.

2. monitoring Sep 11, 2026, 10:47 AM UTC

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

3. resolved Sep 11, 2026, 11:18 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Sep 04, 2026, 02:38 PM UTC· resolved Sep 04, 2026, 03:35 PM UTC

1. monitoring Sep 04, 2026, 02:38 PM UTC

   We are recovering from an incident that caused delays in processing charger updates and affected some OCPP integrations. Our services are available, and delayed information is being processed. Some updates may continue to be delayed while the system catches up. We are monitoring the recovery closely and apologise for the inconvenience.

2. resolved Sep 04, 2026, 03:35 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Sep 04, 2026, 08:29 AM UTC· resolved Sep 11, 2026, 10:47 AM UTC

1. identified Sep 04, 2026, 08:29 AM UTC

   We are currently experiencing an issue with charge report generation in the Zaptec Portal. When attempting to generate a charge report, the report may return no data. We have identified the cause of the issue and are actively working on a fix. The current expected resolution timeframe is early next week. We will provide another update as soon as we have more information.

2. identified Sep 07, 2026, 08:15 AM UTC

   We are continuing to work on a fix for this issue.

3. identified Sep 10, 2026, 12:51 PM UTC

   We are continuing to work on a fix for this issue.

4. resolved Sep 11, 2026, 10:47 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Aug 19, 2026, 04:16 PM UTC· resolved Aug 21, 2026, 11:30 AM UTC

1. investigating Aug 19, 2026, 04:16 PM UTC

   We are currently investigating this issue.

2. identified Aug 19, 2026, 06:20 PM UTC

   The issue has been identified, and a fix is currently being implemented. If you attempt to authorise charging in the Zaptec app, the app may not update immediately. Charging may begin as expected, but the app could continue to show the status as “Authorising.” Navigating away from the charging view and then returning should refresh the status.

3. monitoring Aug 19, 2026, 07:36 PM UTC

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

4. monitoring Aug 19, 2026, 08:18 PM UTC

   Some users may still experience delayed status updates in the Zaptec app when attempting to authorize charging. Charging may begin as expected, but the app could continue to show the status as “Authorizing.” If this occurs, navigating away from the charging view and then returning should refresh the status. We may continue to see intermittent occurrences overnight while we monitor the situation. Thank you for your patience.

5. monitoring Aug 20, 2026, 11:23 AM UTC

   We are continuing to monitor for any further issues.

6. resolved Aug 21, 2026, 11:30 AM UTC

   This incident has been resolved.

7. postmortem Aug 21, 2026, 11:31 AM UTC

   On 19th aug approx 17:30 CEST, we observed issues with chargers on OCPPCloud having trouble. This was caused by some services having communication issues with one of our messaging services, causing it to overflow and preventing new messages from being sent. The issue happens intermittently and throughout the period until mitigation. The service providing live updates to UI \(app and portal\) was scaled down roughly in the time periods below, pending investigation and for mitigation being prepared and applied. 19\.aug 18:00 - 20.aug 09:00 CEST 20\.aug 23:00 - 21.aug 09:00 CEST A fix has been implemented and services are now recovered and operational. The root cause is still unknown and we are still investigating what causes this to happen.

Read the full incident report →

Started Aug 14, 2026, 08:58 AM UTC· resolved Aug 21, 2026, 08:20 AM UTC

1. identified Aug 14, 2026, 08:58 AM UTC

   We have identified an issue in the Zaptec app that causes the app language to be set to English for all users. Our team is implementing a fix, and we will provide an update as soon as it is available.

2. monitoring Aug 21, 2026, 08:19 AM UTC

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

3. resolved Aug 21, 2026, 08:20 AM UTC

   The incident has been resolved.

Read the full incident report →

Started Jul 27, 2026, 02:31 PM UTC· resolved Jul 27, 2026, 04:18 PM UTC

1. investigating Jul 27, 2026, 02:31 PM UTC

   We are currently investigating this issue.

2. monitoring Jul 27, 2026, 02:53 PM UTC

   Currently there is a drop of online chargers in Europe that is connected to LTE-M. This is out of our control, but we are monitoring the situation.

3. resolved Jul 27, 2026, 04:18 PM UTC

   This incident has been resolved.

4. postmortem Jul 27, 2026, 04:18 PM UTC

   Between approximately \*\*15:55 and 17:30 CEST\*\* today, some customers experienced charger connectivity issues, including chargers appearing offline and delayed updates. Service has now recovered and we are continuing to monitor closely. Some delayed updates may continue temporarily while devices replay buffered data. We are still investigating the underlying root cause together with relevant infrastructure/network providers. We're sorry for the disruption

Read the full incident report →

Started Jul 21, 2026, 10:59 AM UTC· resolved Jul 21, 2026, 01:12 PM UTC

1. investigating Jul 21, 2026, 10:59 AM UTC

   We are currently investigating the issue. In the meantime, please visit our Help Center for guidance and support. https://help.zaptec.com/

2. identified Jul 21, 2026, 11:28 AM UTC

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

3. monitoring Jul 21, 2026, 12:30 PM UTC

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

4. resolved Jul 21, 2026, 01:12 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 10, 2026, 06:57 AM UTC· resolved Jun 10, 2026, 09:13 AM UTC

1. investigating Jun 10, 2026, 06:57 AM UTC

   There are currently some issues saving changes on charger level in the Zaptec Portal. Changes on installation level still works as expected. We are investigating this issue.

2. identified Jun 10, 2026, 07:08 AM UTC

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

3. monitoring Jun 10, 2026, 07:29 AM UTC

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

4. resolved Jun 10, 2026, 09:13 AM UTC

   This incident has been resolved.

Read the full incident report →

Started May 03, 2026, 09:07 PM UTC· resolved May 04, 2026, 05:57 AM UTC

1. investigating May 03, 2026, 09:07 PM UTC

   The team is investigating the issue

2. monitoring May 03, 2026, 09:30 PM UTC

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

3. resolved May 04, 2026, 05:57 AM UTC

   This incident has been resolved.

4. postmortem May 04, 2026, 12:02 PM UTC

   ``` # Incident Report – Increased Latency in Charger Data Processing Pipeline # Description On the evening of 3 May 2026, our systems experienced increased latency in the internal pipeline that delivers charger data to downstream services. As a result, processing of the data was delayed. This led to: - Charging sessions starting with delays of up to approximately 20 minutes. - Our public charger-state API experiencing elevated error rates and timeouts for part of the incident window. The issue has since been resolved, and systems have returned to normal operation. # Timeline (Oslo time) ## May 3, 2026 21:00 – Internal monitoring detected that one of our downstream services was falling behind in processing incoming charger data, indicating increased delay in the data pipeline. 21:08 – An alert was triggered and the on-call engineer began investigation. 21:30 – The team identified increased latency in the internal data delivery path responsible for sending charger data to our processing services. 21:58 – A support case was opened with our infrastructure provider for further investigation of the upstream latency. 22:18 As a protective measure to reduce load and avoid excessive state-change events, one of our internal charger state services was temporarily scaled down. As a side effect, our public charger-state API, which depends on this service, started returning more HTTP 500 errors and timeouts as clients cancelled long-running requests. 22:43 – Internal metrics indicated that the downstream processing delay had returned to normal levels. 22:53 – Latency in the internal data delivery path decreased back to normal. 23:07 – Initial status update communicated internally. 23:15 – The previously scaled-down charger state service was restored to normal capacity. 23:16 – The public charger-state API returned to normal behaviour. 23:30 – Scope of the incident was refined and communicated. 23:39 – The backlog of delayed charger data was fully processed. ## May 4, 2026 7:57– The incident was marked as resolved. # Root Cause An internal messaging pipeline responsible for delivering charger data exhibited significantly increased latency. This caused many chargers to repeatedly switch between offline and online states in our systems, generating a high volume of state-change events for downstream components. The additional load from these state changes, combined with the bursty delivery of delayed data, led to further processing delays and directly impacted the charger-state API. # Follow-Up Actions Adding more targeted monitoring and alerting on the latency within our internal data pipeline, so we can identify and mitigate similar issues more quickly. Improving our charger state service so it can detect when there are delays in upstream data delivery and temporarily pause or adjust offline/online detection to avoid large numbers of false transitions. We are continuing to work with our infrastructure provider to better understand the underlying cause of the upstream latency and to reduce the likelihood of recurrence. ```

Read the full incident report →

Started Apr 29, 2026, 08:50 AM UTC· resolved Apr 29, 2026, 10:14 AM UTC

1. investigating Apr 29, 2026, 08:50 AM UTC

   We are currently investigating this issue.

2. monitoring Apr 29, 2026, 09:21 AM UTC

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

3. resolved Apr 29, 2026, 10:14 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 12, 2026, 08:07 PM UTC· resolved Mar 13, 2026, 07:13 AM UTC

1. investigating Mar 12, 2026, 08:07 PM UTC

   We are seeing an increase of charging stations connected to LTE-M in Norway, Sweden and Denmark loosing their network connectivity. We are currently investigating this issue, and will update once we have more information.

2. investigating Mar 12, 2026, 08:38 PM UTC

   We have identified that this incident only affects Zaptec Go and Zaptec Go 2 chargers. The issue impacts both LTE-M and Wi-Fi connectivity and is not limited to the Nordics, but affects a set of chargers globally. Our team is continuing to investigate the root cause and is working to restore stable connectivity as soon as possible. We will share further updates as more information becomes available.

3. monitoring Mar 12, 2026, 09:53 PM UTC

   We have identified the root cause of the connectivity issues affecting Zaptec Go and Zaptec Go 2 chargers and fixes have been implemented. Systems are gradually returning to normal, and chargers are expected to behave as intended within the next few hours. If your charging station won't start charging because of connection issues, you can set it to Stand Alone mode through the Zaptec app to start charging. A guide on how to do this can be found here: https://help.zaptec.com/en-GB/article/use-stand-alone-mode-for-troubleshooting-and-unstable-internet?market=no We will monitor the situation over the night.

4. resolved Mar 13, 2026, 07:13 AM UTC

   This incident have been resolved. Connections have been stable through the night.

5. postmortem Mar 13, 2026, 09:32 AM UTC

   # Summary On the evening of 12 March 2026, starting at approximately 20:45 CET, a subset of Zaptec chargers experienced intermittent connectivity issues. This caused temporary disruptions to charging sessions for affected devices. The issue was resolved by the morning of 13 March 2026. # Impact Up to 50,000 devices, primarily Zaptec Go and Go2 chargers, were affected across all markets. Because our devices are distributed across multiple independent infrastructure clusters, the disruption was limited to a subset of the total fleet. Devices that maintained connectivity continued to operate normally throughout the incident. ‌ # Timeline \(Oslo time\) **12 March 2026** 20:49 – An elevated rate of devices going offline was detected. 20:58 – Automated monitoring triggered a critical alert. 21:00 – The on-call engineering team began investigating. 21:07 – Initial status update communicated internally. 21:19 – The affected infrastructure was scaled up in an attempt to restore connectivity. 21:30 – Scope of the incident was refined and communicated. 21:40 – The team evaluated a regional failover but determined it would affect more devices than the incident itself, so it was held in reserve. 21:52 – A support case was raised with our cloud infrastructure provider. 22:00 – Diagnostic analysis confirmed the connectivity errors originated from an infrastructure-level service disruption outside of Zaptec's control. 22:03 – Devices began reconnecting. 22:30 – Recovery trend continued steadily. 22:34 – Our cloud infrastructure provider confirmed a regional capacity issue affecting device connectivity services in the relevant region. 22:45 – The majority of devices had recovered. Status moved to monitoring. ‌ **13 March 2026** 08:15 – The incident was marked as resolved. # Root Cause The disruption was caused by a capacity constraint within our cloud infrastructure provider's device connectivity services in the affected region. This resulted in intermittent service unavailability for a subset of our chargers. Zaptec's own applications and backend services were not the source of the issue. Once connectivity was restored by the infrastructure provider, all systems resumed normal operation without any additional intervention. # Resolution Our engineering team identified the affected device segment within minutes and took immediate steps to mitigate the impact, including scaling up infrastructure resources. A regional failover was evaluated but intentionally held back, as it would have introduced a broader disruption than the incident itself. Once the root cause was confirmed as an external infrastructure issue, the team monitored the recovery closely until full connectivity was restored. ## Follow-Up Actions Failover readiness: We will conduct controlled failover exercises in production to increase our confidence and speed of response in the event of larger-scale disruptions. Faster offline detection: We are improving our monitoring systems to detect and respond to connectivity issues more quickly, reducing time to resolution in future incidents.

Read the full incident report →

Started Feb 16, 2026, 07:45 AM UTC· resolved Feb 16, 2026, 08:19 AM UTC

1. investigating Feb 16, 2026, 07:45 AM UTC

   We've received reports of issues creating new installations in the Zaptec Portal. We are investigating this issue.

2. resolved Feb 16, 2026, 08:19 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Feb 13, 2026, 11:30 PM UTC· resolved Feb 13, 2026, 11:30 PM UTC

1. resolved Feb 14, 2026, 07:45 AM UTC

   Disruption across all instances of the service, impacting major API-driven integrations.

2. postmortem Feb 14, 2026, 07:45 AM UTC

   2026-02-14 — API Disruption During the night of 2026-02-14, between 00:23 and 04:20 \(CET\), our public API experienced a significant disruption across all instances of the service, impacting major API-driven integrations. Core charging subsystem and OCPP-managed chargers were not affected, so general charging continued to operate normally. However, configuration modifications on installation level were temporarily unavailable during this period. Timeline 00:23 – Problematic behavior started 01:18 – The issue was reported to us by an integration partner 01:30 – Engineering investigation began 02:30 – Rate limiting was applied on all API routes in an attempt to recover from a restart loop, but that didn't stabilize the system. 03:10 – Application profiling was disabled to reduce overhead on the loaded system. No positive impact observed. 03:45 – /api/installation routes were isolated to a separate set of instances to contain the impact of disruption. 03:55 – Rate limiting on / was reverted; traffic patterns began to normalize 04:20 – System stabilized Root Cause Analysis The incident is still under active investigation. Current working theories include: Heavy query load — Certain endpoints may have been executing queries with unexpectedly high processing costs, contributing to system strain. Infrastructure networking issues — There are indications of underlying networking instability in the hours leading up to the incident, which may have been a contributing factor. Increased external traffic — A significant increase in request volume on resource-intensive endpoints may have triggered or amplified the disruption. We are continuing to investigate and will implement safeguards and optimizations on the affected endpoints to reduce the likelihood of similar incidents in the future. A follow-up update will be provided once the root cause has been confirmed.

Read the full incident report →

Started Feb 11, 2026, 09:29 AM UTC· resolved Feb 17, 2026, 02:19 PM UTC

1. investigating Feb 11, 2026, 09:29 AM UTC

   We are currently investigating a bug in the app where users occasionally lose access to their charger. The issue is temporarily resolved by logging out of the app and then logging back in.

2. investigating Feb 11, 2026, 10:50 AM UTC

   We are continuing to investigate this issue.

3. investigating Feb 11, 2026, 02:04 PM UTC

   We are still investigating this issue.

4. investigating Feb 12, 2026, 07:49 AM UTC

   We are still investigating this issue. If you are experiencing any issues with access to charging stations through the Zaptec app, please sign out and back in.

5. identified Feb 12, 2026, 01:33 PM UTC

   The issue has been identified, and we are working on a fix.

6. monitoring Feb 16, 2026, 08:21 AM UTC

   A fix has been implemented and we are currently monitoring the results. To ensure the issue is fully resolved, please update your Zaptec app to version 5.41.9 on iOS (Apple).

7. monitoring Feb 16, 2026, 10:50 AM UTC

   We are continuing to monitor for any further issues. To ensure the issue is fully resolved, please update your Zaptec app to version 5.41.9 on iOS (Apple). To verify the current version of your app, click on the "Account" tab in the lower right corner inside the Zaptec App. You will then see the version number in the bottom of your screen.

8. resolved Feb 17, 2026, 02:19 PM UTC

   This incident has been resolved.

9. postmortem Feb 17, 2026, 02:19 PM UTC

   ## Summary Following the release of iOS version 5.41.8, some users experienced authorization errors that affected access to certain app features. Users were not fully blocked, and access could be restored by signing out and back in. The issue was quickly identified and resolved. A corrected version of the app was expedited through App Store review, approved on Friday at 21:34, and verified in production. ## Timeline \*\*2026-02-11 — Afternoon\*\* — Version 5.41.8 released. \*\*2026-02-12 — Midday\*\* — Elevated authorization errors detected. \*\*2026-02-12 — Afternoon\*\* — Investigation initiated. \*\*2026-02-13 — Afternoon\*\* — Root cause identified and fix implemented. \*\*2026-02-13 — 21:34\*\* — Patched version approved and released \(Version 5.41.9\). \*\*Post-release\*\* — Monitoring confirmed the issue was resolved. ## Root Cause An issue introduced during the app update impacted authentication for a subset of users. ## Resolution The team implemented a fix, validated it through internal testing, and released the updated version following expedited review. Additional safeguards have been put in place to reduce the risk of similar issues in future releases.

Read the full incident report →

Started Jan 28, 2026, 07:53 AM UTC· resolved Jan 28, 2026, 09:15 AM UTC

1. investigating Jan 28, 2026, 07:53 AM UTC

   We are currently investigation the issue, contact us here: https://forms.atender.com/form/b06xo3dlmls-copy-1768225820551?lang=en

2. identified Jan 28, 2026, 08:02 AM UTC

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

3. monitoring Jan 28, 2026, 08:10 AM UTC

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

4. resolved Jan 28, 2026, 09:15 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Jan 16, 2026, 05:06 PM UTC· resolved Jan 17, 2026, 10:08 AM UTC

1. investigating Jan 16, 2026, 05:06 PM UTC

   We are currently investigating an issue where a small percentage of devices may show delayed history of observations. This does not affect the charging process. No action is required from users, and all data will appear as expected once the system catches up

2. identified Jan 16, 2026, 09:08 PM UTC

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

3. monitoring Jan 16, 2026, 09:31 PM UTC

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

4. resolved Jan 17, 2026, 10:08 AM UTC

   This incident has been resolved.

5. postmortem Jan 19, 2026, 08:46 AM UTC

   On January 16, 2026, we experienced a delay in processing historical observation data for a small subset of devices. This affected how historical data was displayed in the portal, but did not impact charging functionality or real-time device status. We want to provide a transparent overview of what happened, how we responded, and the steps we are taking to prevent this from happening again. \# Impact Approximately 5% of devices experienced delays in displaying historical observation data in the portal. \## Importantly: \* Charging sessions and charging performance were not affected \* Real-time device status remained accurate \* No impact on safety or system stability \* All delayed data has since been fully processed and is now available in the portal. \# Timeline 14:40 – A customer reported that historical observation data for their device appeared delayed in the portal, while real-time status was accurate. 15:30 – Our team identified that the issue was isolated to the historical data processing pipeline for a small subset of devices. 16:30 – Investigation revealed the issue had begun approximately 24 hours earlier, with delays gradually accumulating over time. 18:00 – An incident response team was assembled and a status notification was posted on the portal. 18:00–21:00 – The team investigated multiple potential causes and tested various solutions. 22:00 – An optimized version of the data processing service was deployed, and the system immediately began recovering. 22:30 – All delayed data was fully processed and historical observations were up to date. \# Root Cause Under normal conditions, the system processed device observations without issue. However, when certain devices began transmitting duplicate observations at a higher rate than usual, the data processing pipeline was unable to keep pace. This caused a backlog that grew over time, resulting in delayed historical data for approximately 5% of devices. \## Resolution We deployed an optimized data processing method that handles higher volumes of observations more efficiently. The backlog was fully cleared and all historical data is now current. \## Preventive Measures To prevent similar issues in the future, we have: \* Improved the efficiency of our data processing pipeline \* Enhanced monitoring to detect processing delays earlier \* Implemented automated alerts to notify our team of any ingestion delays We apologize for any inconvenience this may have caused.

Read the full incident report →

Started Dec 05, 2025, 09:08 AM UTC· resolved Dec 05, 2025, 11:58 AM UTC

1. investigating Dec 05, 2025, 09:08 AM UTC

   Due to 3rd party service being down, our support systems are currently unavailable. This means that our customers can't reach our support. This is currently out of our control and we are monitoring the situation. All other services are operational. https://www.cloudflarestatus.com/

2. monitoring Dec 05, 2025, 09:24 AM UTC

   A fix has been implemented by the 3rd party service. We will continue to monitor.

3. resolved Dec 05, 2025, 11:58 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Dec 04, 2025, 11:45 AM UTC· resolved Dec 04, 2025, 01:38 PM UTC

1. monitoring Dec 04, 2025, 11:45 AM UTC

   Currently there is a drop of online chargers in Denmark that is connected to LTE-M. This is out of our control, but we are monitoring the situation.

2. monitoring Dec 04, 2025, 12:31 PM UTC

   Connections are improving. We will still monitor the situation.

3. resolved Dec 04, 2025, 01:38 PM UTC

   This incident has been resolved.

Read the full incident report →