Voyado Outage History

## Summary On April 23rd, approximately between 15:55 and 16:27 CET, our FTP service experienced an outage after the underlying infrastructure became unresponsive due to a spike in CPU usage. The service was restored after corrective actions were taken. After recovery, we verified stability and completed follow-up maintenance to reduce operational risk. ## Customer Impact During the incident, FTP connections and transfers were unavailable for customers using the FTP service. Once recovery actions were completed, the service resumed normal operation. ## Root Cause The incident was triggered by an unexpected spike in CPU usage that caused the underlying infrastructure to become unresponsive. As a result, the FTP service stopped responding and could not be reached for troubleshooting until corrective actions were taken. ## Mitigation * Took corrective actions on the affected infrastructure to restore FTP availability. * Confirmed the FTP service was running normally and serving traffic after recovery. * Performed follow-up maintenance to reduce operational risk. ## Next Steps Improve resilience for the FTP service to reduce the risk of similar outages. We apologize for the disruption this caused, and we appreciate your patience while we worked to restore the service.

## Summary On the afternoon of 20 March, we experienced a disruption affecting Vipps and Treazure integrations. The investigation showed that the issue was caused by a very large burst of webhook-triggering updates from one customer workflow. The issue was mitigated the same day by disabling the affected workflow, after which service returned to normal. ## Customer Impact Multiple customers experienced failed or interrupted external API call activities connected to Vipps flows, and some impact was also seen in Treazure flows. This resulted in timeouts and failed processing during the incident window. ## Root Cause The incident was caused by a massive simultaneous burst of webhook-triggering updates from one customer workflow, which overloaded the shared integration service. This created performance issues in the integration layer and affected Vipps and Treazure integrations using the same service. ## Mitigation After the source of the traffic spike was identified, the affected webhook endpoint was disabled and the customer integration with Treazure was temporarily deactivated. This reduced the load on the integration service and restored normal behaviour for other tenants. ## Next Steps To reduce the risk of similar incidents in the future, we are: * Reviewing throttling and rate-limiting for webhook traffic * Reviewing monitoring and alerting for the integration * Strengthening guidance and communication around high-volume customer automations We apologize for the inconvenience this incident may have caused and appreciate your understanding.

## Summary On March 15th 2026, an issue affecting Delta Share was identified. The issue was caused by a change in how timestamp values were stored. This change was introduced as part of an infrastructure upgrade on March 13, 2026. The incident was limited in scope and, based on our investigations, only one tenant/partner was affected. ## Customer impact One tenants/partners Delta Share integration failed when loading data containing timestamp fields. This meant that some shared data could not be processed correctly in their integration. At this time, no other Delta Share users have been identified as affected. ## Root cause As part of an upgrade, the infrastructure used to prepare shared data was moved to a newer cluster setup. Following this change, timestamp values were written in a different format than before. While the data itself remained correct and available, one partner integration was not able to handle the new timestamp format. ## Mitigation We worked directly with the partner that was affected by the issue after the issue was reported. The partner updated their integration to support the new timestamp format, which resolved the issue. We also evaluated whether to revert to the previous format, but decided not to do so since no other users appeared to be affected and a rollback would have required significant additional work for the impacted partner. ## Next steps To reduce the risk of similar issues in the future, we are taking the following actions: * Evaluating validation of data types when making infrastructure changes We are sorry for the inconvenience this caused.

A recent network configuration update unintentionally interrupted communication between the Elevate App backend and a subset of Elevate clusters. Because DNS records were still being served from cache, the change didn’t take effect right away. Once those cached entries expired, the loss of connectivity surfaced. This timing gap made it harder to connect the incident to the earlier change, which extended our troubleshooting and recovery time.