No incidents reported
FoxESS inverters that were being curtailed during the time of a release on the 26th Aug. around 11:36 weren't able to correctly lift those limits causing suboptimal control.
Resolved after 0m
What happened: Between 16:42 and 07:38 CEST, charging control decisions for cloud connected EVs were temporarily not executed. Affected vehicles remained in their last known state for the duration of the incident.
Impact: Approximately 5% more charging sessions missed their target compared to baseline. The majority of charging sessions completed successfully. No data was lost, and all systems resumed normal operation automatically after the issue was resolved.
Resolution: A fix was deployed and normal operation was restored by 07:38 CEST on August 12.
Resolved after 0m
A scheduled maintenance window will take place on August, 3rd, from 08:30 to 09:30 CET. During this time, you may experience brief service disruptions.
The maintenance work has been completed successfully.
There won't be any interruptions or rejections for the Webhook Subscription API anymore.
The bug was identified and fixed.
Resolved after 46m
On 2026-07-22, a coordinated release across the customer-facing frontends caused widespread 401 authentication errors for users. The issue stemmed from a change in the authentication flow and an audience configuration change. The backend’s newly tightened validation logic rejected these tokens, causing users to be unable to log in or maintain their sessions.
Between 09:30 and 10:15 CEST, users attempting to authenticate were partially met with 401 errors. This disrupted normal frontend operations. While the primary issue was mitigated within 45 minutes, residual errors persisted for several hours due to browser-side caching of the previous frontend version.
The incident was caused by two intersecting factors:
* Backend validation: The backend was updated to implement stricter validation on JWT audience claims.
* Frontend refresh logic: The frontends' token refresh flow - when requesting a new access token - was returning multiple audiences in a way that did not match the strict expectations set by the backend.
The configuration change moved the frontends to a new audience, which triggered this mismatch, whereas the previous configuration had relied on legacy behavior that the backend was no longer implicitly supporting.
The incident was detected by automated alerts which fired shortly after the v5.13.0 rollout.
The following steps were taken to mitigate and resolve the incident:
* Rollback: The frontend changes were rolled back to the previous stable versions for both frontends.
* Backend Configuration: The backend validation logic was amended to temporarily allow the legacy audience value, ensuring that existing sessions remained valid while the frontend could be safely updated.
Resolved after 1d