Axway 장애 기록

1. 2026년 8월 18일 오후 8:05 UTCinvestigating

   우리는 19 : 40 UTC에서 18 8 월 2026, 사용자의 수는 로그인 실패를 경험 할 수있는 동안 고급 인증 서비스의 간단한 기간을 관찰했습니다. 우리는 현재 문제를 조사하고 있습니다.

2. 2026년 8월 18일 오후 9:54 UTCresolved

   이 사건은 해결되었습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 11일 오후 12:02 UTCresolved

   We observed a brief period of degraded authentication service between 05:50 UTC and 06:50 UTC on 11 August 2026, during which a small number of users may have experienced login failures. The issue has been fully resolved, and services are operating normally. Additional monitoring and preventive measures have been put in place to help maintain service reliability. We regret any disruption this may have caused and appreciate your continued trust.

1. 2026년 5월 11일 오후 4:19 UTCresolved

   Unbounded queries overwhelmed the analytics systems in use by Engage and Platform, causing delays in processing between 2PM-3PM UTC today. We will be working to improve query size and performance as well as introduce further restrictions to prevent this from causing issues in the future.

1. 2026년 2월 19일 오후 5:28 UTCresolved

   We’re sorry — between 13:00 UTC and 14:00 UTC today some customers experienced partial interruptions to Axway Platform, Axway Analytics, Amplify Marketplace, and Amplify Engage. During that window an internal service error caused elevated failures and automated retries, which temporarily prevented normal access for some users. We restored access by allowing queued requests to proceed while we validated and deployed a tested fix; normal service was confirmed at 14:00 UTC. No customer data was exposed. We’re taking steps to reduce the chance of this happening again, including additional safeguards, improved test coverage, and broader alerting so production issues are surfaced to our public status page and support teams more quickly. If you’re still seeing problems or need help, please contact support through your usual channels.

1. 2025년 12월 12일 오전 10:13 UTCresolved

   Description: During the detected outage on Amplify Studio, users experienced instability in activating integrations. Additionally, the receipt of monitoring data from Fusion was affected. Root Cause: The introduction of additional monitoring checks in the environments led to a permissions error on the clusters. This error disrupted connectivity between the Studio and Fusion instances. The standard validation routines prior to being deployed in production didn’t catch this permission mismatch. Corrective Action: The permissions were promptly reverted, and impacted services were verified. To prevent recurrence, we have implemented additional checks to ensure such changes do not affect production without being detected in lower environments first.

1. 2025년 5월 7일 오후 4:42 UTCinvestigating

   We are currently experiencing a major disruption in our EU production environment where event processing has stopped for the majority of services. This issue is impacting several critical functions, including but not limited to: - Product and asset releases (publish/unpublish) - Credential and access request processing - Subscription management - Agent and webhook event delivery Our engineering team is actively working to resolve the invalid event entries to resume normal processing. Once the blockers are cleared, queued and new events will begin processing as expected.

2. 2025년 5월 7일 오후 4:43 UTCinvestigating

   We are continuing to investigate this issue.

3. 2025년 5월 7일 오후 8:43 UTCidentified

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

4. 2025년 5월 7일 오후 9:14 UTCresolved

   This incident has been resolved.

1. 2025년 2월 25일 오전 9:10 UTCresolved

   Date: Start Friday 21st - 08:02 AM End Friday 21st - 12:23 PM Impact: The Shared Data Plane experienced an outage, resulting in the interruption of transaction processing. Details: During the startup of new worker nodes two issues were discovered. The startup of the CNI plugin failed and was therefore not initialized. A CNI plugin is required to implement the Kubernetes network model. The second issue was due to the EFS plugin crashing with OOM. EFS is used for persistent storage. To resolve the issue, the memory was increased and unstable nodes were restarted. After these actions the Shared Data Plane returned to a stable state and the outage ended.

1. 2025년 2월 11일 오후 4:13 UTCresolved

   Date: February 5-6, 2024 (Start time after 22:00 UTC on February 5th; end time 09:20 UTC on February 6th) Impact: The Shared Data Plane experienced an outage, resulting in the interruption of transaction processing. Description: A thorough investigation of system logs revealed a disruption in network connectivity between nodes within the Hazelcast cluster. Hazelcast serves as the messaging layer between various components in our Orchestrator. The network disruption prevented communication between these critical components, halting message processing and consequently, transaction processing. Corrective Actions & Future Plans: A root cause analysis is underway to determine the specific cause of the network disruption within the Hazelcast cluster. Aside from this analysis, the team is planning to replace Hazelcast with an alternative messaging platform. Enhancements to the monitoring framework are implemented to proactively detect and alert on similar connectivity issues, enabling prompt intervention and minimizing service disruption.

1. 2023년 8월 29일 오후 4:26 UTCresolved

   During a certificate upgrade, a rogue certificate caused a tremendous increase of the CPU of Axway Platform and other services that were inaccessible.

1. 2022년 1월 17일 오전 8:11 UTCidentified

   The planned upgrade from RDS 9.6 to 13.3 is taking longer than initially expected. The reason is identified and we are working to get Central up and running again ASAP. The estimated time of resolution and full functionality restoration is 35 minutes.

2. 2022년 1월 17일 오전 8:38 UTCresolved

   This incident has been resolved.

1. 2022년 1월 14일 오전 10:08 UTCinvestigating

   The planned upgrade from RDS 9.6 to 13.3 is taking longer than initially expected. The reason is identified and we are working to get Central up and running again ASAP.

2. 2022년 1월 14일 오전 10:09 UTCinvestigating

   We are continuing to investigate this issue.

3. 2022년 1월 14일 오전 10:09 UTCidentified

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

4. 2022년 1월 14일 오전 10:11 UTCmonitoring

   A fix has been successfully implemented and the service is up and running again. We are closely monitoring the situation, however, we don't expect additional outage. A post mortem analysis is on the way.

5. 2022년 1월 14일 오전 11:40 UTCresolved

   The incident has been resolved.

1. 2021년 2월 12일 오후 8:53 UTCresolved

   During the deployment of static I.P. addresses for Amplify Central (as noted at the URL below), our engineers encountered unexpected issues with our DNS service which caused the Amplify Central administration interface and Unified Catalog (U.S. only) to to be unreachable. Our engineers worked to resolve the issue and service was restored after approximately 39 minutes. Notification of Static I.P. addresses: https://status.axway.com/incidents/jmy8d6fzwdlh

1. 2019년 10월 1일 오전 3:34 UTCresolved

   On Saturday, September 28th, Axway upgraded the access management capabilities of the AMPLIFY Platform in the production environment. During that upgrade, at 10:03 AM PDT, a regression happened which the product team promptly stopped with a hot fix (note: a patch is going in shortly to resolve the problem more permanently). On Monday, September 30th, at 9:40 AM PDT, it was discovered that the regression had caused a few single-user organizations to lose at least part of their data. The same day, at 4:40 AM PDT, all data had been fully restored and the incident had been marked as resolved. Axway will be contacting each one of the organizations affected by this temporary loss of data. Already, we want to apologize to these customers for the inconvenience or disruption that this may have caused. The product team systematically conducts full regression tests before any upgrade; this time, there was an edge case flow that we missed in our testing and that led to that incident in production. We are taking steps to prevent the reoccurrence of a similar situation in the future.