Fluid Attacks Outage History

Started Jan 23, 2026, 08:40 PM UTC· resolved Jan 23, 2026, 09:03 PM UTC

1. identified Jan 23, 2026, 08:51 PM UTC

   The Vulnerabilities section fails to load correctly, preventing users from accessing and reviewing vulnerability information within the platform.

2. resolved Jan 23, 2026, 09:03 PM UTC

   The incident has been resolved, and the vulnerabilities section is now loading correctly.

3. postmortem Jan 23, 2026, 10:07 PM UTC

   **Impact** An unknown number of users experienced issues when accessing the Vulnerabilities section, where the information failed to load as expected. The issue started on UTC-5 26-01-23 13:47 and was proactively discovered 57.6 minutes \(TTD\) later by an automated code analysis process and later corroborated by reports from staff members and clients. The problem was resolved in 43.2 minutes \(TTF\), resulting in a total window of exposure of 1.6 hours \(WOE\) [\[1\]](https://gitlab.com/fluidattacks/universe/-/issues/20193). **Cause** A typing mistake caused a variable to be assigned an unexpected data structure. This mismatch led to a failure when the system attempted to retrieve information from the search service, resulting in errors that blocked the display of findings [\[2\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/93122). **Solution** The code was corrected to ensure the variable is assigned using the expected format. This allowed the system to properly construct the request and successfully retrieve the required data [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/93130). **Conclusion** The incident underscored the importance of stronger safeguards around data handling in search queries. As a result, improvements will be made to enforce stricter typing and reduce the likelihood of similar issues affecting users in the future. **INCOMPLETE\_PERSPECTIVE < MISSING\_TEST**

Read the full incident report →

Started Dec 31, 2025, 05:02 AM UTC· resolved Jan 02, 2026, 01:53 PM UTC

1. identified Jan 15, 2026, 01:45 PM UTC

   It was identified that the CI Gate and services that depend on the API are currently failing.

2. resolved Jan 15, 2026, 01:47 PM UTC

   The incident has been resolved, and the affected services are now operating normally.

3. postmortem Jan 15, 2026, 02:13 PM UTC

   **Impact** At least one user experienced service interruptions affecting the agent and other features that depend on the API. The issue started on UTC-5 25-12-29 22:25 and was proactively discovered 3.7 days \(TTD\) later by one of our monitoring tools, which reported failures in several system components. While investigating these alerts, the team identified that background processes required for the service to operate were not running correctly. The problem was resolved in 1.6 hours \(TTF\), resulting in a total window of exposure of 3.7 days \(WOE\) [\[1\]](https://gitlab.com/fluidattacks/universe/-/issues/19803). **Cause** A required access key was missing from the production configuration. The key had been removed by mistake, which caused background processes to fail, and as a result, any functionality that depended on them stopped working [\[2\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/91520/diffs). **Solution** The missing access key was restored in the production configuration file, allowing the system to authenticate properly and resume normal operations [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/91677). **Conclusion** Once the key was restored, all affected components recovered, and the service returned to normal. This incident emphasizes the importance of safeguarding critical configuration values to prevent widespread service disruptions. **INFRASTRUCTURE\_ERROR**

Read the full incident report →

Started Dec 19, 2025, 03:32 PM UTC· resolved Dec 19, 2025, 05:13 PM UTC

1. identified Dec 19, 2025, 03:32 PM UTC

   It has been identified that the platform is currently unable to generate reports.

2. resolved Dec 19, 2025, 05:13 PM UTC

   The incident has been resolved, and the platform is now able to generate reports as expected.

3. postmortem Dec 19, 2025, 09:31 PM UTC

   **Impact** At least three users experienced problems when trying to generate reports on the platform. The issue started on UTC-5 25-12-18 16:47 and was reactively discovered 15.3 hours \(TTD\) later by a client who reported through our help desk [\[1\]](https://help.fluidattacks.com/agent/fluid4ttacks/fluid-attacks/tickets/details/944043000058065001) that reports could not be generated correctly. During the investigation, we found that several background processes related to actions such as disabling roots, updating attack surfaces, and applying organization policies were not being processed as expected. The problem was resolved in 2.8 hours \(TTF\), resulting in a total window of exposure of 18.2 hours \(WOE\) [\[2\]](https://gitlab.com/fluidattacks/universe/-/issues/19655). **Cause** The problem was caused by a recent change where some code was removed, but other parts of the system were still trying to use it. Additionally, the component responsible for handling background tasks was being checked with very basic validation rules, which were not strong enough to detect this type of issue before it reached production [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/90970). **Solution** All remaining references to the removed code were cleaned up, allowing the affected background processes to run correctly again and restoring normal report generation [\[4\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/91025). **Conclusion** As a follow-up action, we will prioritize strengthening the validation rules used for this part of the system so that similar issues can be detected earlier and prevented in the future. **INCOMPLETE\_PERSPECTIVE < MISSING\_TEST**

Read the full incident report →

Started Dec 04, 2025, 05:21 PM UTC· resolved Dec 04, 2025, 07:24 PM UTC

1. identified Dec 12, 2025, 08:28 PM UTC

   It has been identified that the Platform is experiencing a temporal accessibility degradation.

2. resolved Dec 12, 2025, 08:28 PM UTC

   The incident has been resolved, and the platform is now operating normally.

3. postmortem Dec 12, 2025, 08:37 PM UTC

   **Impact** At least one user experienced a brief service interruption. The issue started on UTC-5 25-12-04 14:20 and was proactively discovered 1 minute \(TTD\) later by a staff member who noticed that the platform stopped responding for a few minutes during an update. The problem was resolved in 3 minutes \(TTF\), resulting in a total window of exposure of 4 minutes \(WOE\) [\[1\]](https://gitlab.com/fluidattacks/universe/-/issues/19338). **Cause** While we were improving the machines that run the service, the system replaced the old ones with new ones. However, it turned off all the old machines before the new ones were fully ready, leaving the platform with no way to handle incoming requests for a short period of time [\[2\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/90009). **Solution** A safeguard was added so the system cannot turn off any machine until at least one new one is fully ready. This ensures the service always stays available during updates [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/90085). **Conclusion** The fix applied ensures that new machines must be ready before old ones are removed. We are also working on performance improvements and will continue reviewing how the system behaves in these situations to see if more protections are needed. **INFRASTRUCTURE\_ERROR < PERFORMANCE\_DEGRADATION**

Read the full incident report →

Started Nov 28, 2025, 08:45 PM UTC· resolved Nov 28, 2025, 09:00 PM UTC

1. identified Dec 01, 2025, 10:34 PM UTC

   It has been identified that a timeout error in one of the core API services caused requests to exceed the expected response time. This issue led to noticeable degradation across the platform.

2. resolved Dec 01, 2025, 10:35 PM UTC

   The incident has been resolved, and all API services are now operating as expected.

3. postmortem Dec 01, 2025, 10:54 PM UTC

   **Impact** At least one user experienced difficulties while trying to review vulnerabilities, as the platform failed to load correctly. The issue started on UTC-5 25-11-28 15:23 and was proactively discovered 21 minutes \(TTD\) later by a staff member who reported through our help desk [\[1\]](https://help.fluidattacks.com/agent/fluid4ttacks/fluid-attacks/tickets/details/944043000055824645) that the vulnerabilities view remained stuck in a loading state. Following this initial report, an additional customer report arrived, confirming that the problem was affecting multiple users. The problem was resolved in 10 minutes \(TTF\), resulting in a total window of exposure of 31 minutes \(WOE\). **Cause** A large batch of approximately 3,900 automated tasks was executed against the platform. Each task performed several operations that required intensive use of the system, and up to 200 of them were running simultaneously. This created a sudden and unusually high amount of activity that the platform was not able to handle quickly enough. Because the platform needs several minutes to increase its capacity when activity spikes, it continued receiving more and more requests before it was ready to support them. This led to delays, timeouts, and error responses for about half an hour, affecting both the automated tasks and regular users who were trying to interact with the platform during that period. The incident was not caused by a recent update, but rather by a combination of a huge volume of simultaneous work and the current limitations of the platform’s ability to adapt to sudden increases in demand. **Solution** Stopping the ongoing tasks was not possible because, by the time the cause was clearly identified, most of them had already been submitted and were nearly complete. The situation was monitored closely until the workload naturally decreased. Once the activity level went down, the platform gradually recovered and returned to normal operation. **Conclusion** To prevent similar incidents, we will avoid generating large, highly concurrent workloads against the platform until it is better prepared to support them, adjust internal workflows so the platform receives fewer unnecessary requests, and continue improving its ability to scale more quickly during periods of high demand, ensuring greater stability and a smoother experience for all users. **PERFORMANCE\_DEGRADATION < INCOMPLETE\_PERSPECTIVE**

Read the full incident report →

Started Nov 27, 2025, 05:15 PM UTC· resolved Nov 28, 2025, 12:39 AM UTC

1. identified Nov 28, 2025, 12:50 PM UTC

   It has been identified that several processes responsible for tasks such as updating Git roots, executing scans, generating reports, and other core services, are currently failing. Our engineering team is actively working to restore normal functionality.

2. identified Nov 28, 2025, 12:50 PM UTC

   We have traced the source of the issue and are actively working on the necessary corrections.

3. identified Nov 28, 2025, 12:54 PM UTC

   The solution is currently being implemented. We will provide another update once the services are fully stabilized

4. resolved Nov 28, 2025, 12:55 PM UTC

   The incident has been resolved, and all affected operations are operating as expected.

5. postmortem Nov 28, 2025, 01:29 PM UTC

   **Impact** At least one user observed failures in several features of the platform. The issue started on UTC-5 25-11-27 09:25 and was proactively discovered 1.9 hours \(TTD\) later by a staff member who noticed that some processes were not running as expected. Shortly after this internal detection, customer reports also began to arrive, confirming the problem. The problem was resolved in 7.6 hours \(TTF\), resulting in a total window of exposure of 9.6 hours \(WOE\) [\[1\]](https://gitlab.com/fluidattacks/universe/-/issues/19189). **Cause** The infrastructure used by some services was decommissioned, even though those services were still dependent on it. This led to interruptions in functionalities related to repository cloning, reattacks, report generation, and other operations handled by the affected components [\[2\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/89521). **Solution** New infrastructure definitions were created, and the systems were updated to use them. This included refreshing the internal configurations so that all processes pointed to the correct, active infrastructure [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/89638). **Conclusion** To prevent similar issues in the future, we are improving how infrastructure ownership is structured. Each component will become clearly responsible for the infrastructure it depends on, making those relationships visible and reducing the chances of accidental removal of shared resources. **INFRASTRUCTURE\_ERROR < INCOMPLETE\_PERSPECTIVE**

Read the full incident report →

Started Nov 24, 2025, 06:53 PM UTC· resolved Nov 24, 2025, 11:30 PM UTC

1. identified Nov 25, 2025, 06:53 PM UTC

   An issue has been identified affecting the verification process for reattack requests.

2. resolved Nov 25, 2025, 07:04 PM UTC

   The incident has been resolved, and reattack requests are now being processed correctly.

3. postmortem Nov 25, 2025, 07:35 PM UTC

   **Impact** At least one user experienced issues with reattack processing. The issue started on UTC-5 25-11-21 12:39 and was reactively discovered 3 days \(TTD\) later by a client who reported through our help desk [\[1\]](https://help.fluidattacks.com/agent/fluid4ttacks/fluid-attacks/tickets/details/944043000055268001) that reattacks remained stuck in the REQUESTED state for many hours after being submitted. The problem was resolved in 4.3 hours \(TTF\), resulting in a total window of exposure of 3.2 days \(WOE\) [\[2\]](https://gitlab.com/fluidattacks/universe/-/issues/18164). **Cause** A combination of issues led to the issue: a bug introduced in the vulnerability-reporting system prevented the reattack results produced after the SAST\+SCA scan from being processed, affecting all reattacks requested; the fix for this bug was delayed for several hours because the affected namespace was unable to deploy updates or scale correctly; and a second backend issue in the cloning flow disrupted the scheduler responsible for re-queuing reattacks that had been waiting for long periods, leaving them stuck in the REQUESTED state [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/88658),[\[4\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/89135). **Solution** To fully restore correct behavior, the processing of static scan inputs was wrapped in a robust error-handling block that logs detailed information and notifies the workflow engine when failures occur, preventing silent interruptions, and the logic responsible for checking existing jobs was updated to include the scheduler that retries delayed reattacks, ensuring these tasks are properly recognized and processed [\[5\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/89274),[\[6\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/89313). **Conclusion** A processing bug, a deployment issue, and a scheduler logic flaw caused the incident. All contributing issues have now been fixed. Reattacks are once again processed reliably, and additional safeguards were added to ensure that failures in report processing and job scheduling are detected and handled safely in the future. **INFRASTRUCTURE\_ERROR < UNHENDLED\_EXCEPTION < INCOMPLETE\_PERSPECTIVE**

Read the full incident report →

Started Nov 18, 2025, 02:34 PM UTC· resolved Nov 18, 2025, 03:10 PM UTC

1. identified Nov 18, 2025, 02:34 PM UTC

   An ongoing widespread disruption in Cloudflare's core services is currently impacting our platform, the Agent, and all API-dependent services. Click for details: https://www.cloudflarestatus.com/

2. resolved Nov 18, 2025, 03:37 PM UTC

   The incident has been resolved, and all Fluid Attacks services are now operating normally.

3. postmortem Nov 18, 2025, 04:11 PM UTC

   **Impact** At least one user experienced service interruptions across the platform, the agent, and all API-dependent functionalities. The issue started on UTC-5 25-11-18 08:58 and was proactively discovered 14.4 minutes \(TTD\) later by one of our monitoring tools, which detected a generalized degradation in service availability, which aligned with a major [Cloudflare incident](https://www.cloudflarestatus.com/incidents/8gmgl950y3h7) affecting global traffic routing. As a result, several core operations across our ecosystem were temporarily unable to function as expected. The problem was resolved in 43.2 minutes \(TTF\), resulting in a total window of exposure of 57.6 minutes \(WOE\). **Cause** Cloudflare experienced a global network performance issue that affected its edge infrastructure. Because Cloudflare is part of the delivery path for our services, the degradation prevented requests from being routed and processed correctly, resulting in timeouts and temporary unavailability. **Solution** No internal action was required. Once Cloudflare resolved the underlying network issue and service performance returned to normal, all affected components on our side recovered automatically. **Conclusion** This event reinforces the operational impact that third-party infrastructure outages can have on our services. We will continue closely monitoring external provider incidents and evaluating ways to improve resilience and early detection for future occurrences. **THIRD\_PARTY\_ERROR**

Read the full incident report →

Started Nov 12, 2025, 09:00 PM UTC· resolved Nov 12, 2025, 11:45 PM UTC

1. identified Nov 18, 2025, 03:38 PM UTC

   It has been identified that Fixes are not being generated in the extension or the platform due to an “Endpoint request timed out” error.

2. resolved Nov 18, 2025, 03:42 PM UTC

   The incident has been resolved, and fix generation within the extensions and the platform has been restored to normal operation.

3. postmortem Nov 18, 2025, 03:49 PM UTC

   **Impact** At least one user encountered consistent failures when attempting to generate fixes. The issue started on UTC-5 25-11-11 17:11 and was proactively discovered 22.8 hours \(TTD\) later by a staff member through our help desk [\[1\]](https://help.fluidattacks.com/agent/fluid4ttacks/fluid-attacks/tickets/details/944043000053690769) that the extension and the platform displayed an `Endpoint request timed out` message when trying to generate a fix. The problem was resolved in 2.4 hours \(TTF\), resulting in a total window of exposure of 1 day \(WOE\) [\[2\]](https://gitlab.com/fluidattacks/universe/-/issues/18852). **Cause** During an internal infrastructure update, the component responsible for generating fixes was assigned an incorrect permission. This prevented it from communicating with the API that processes fix requests, causing the system to time out instead of returning a result [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/88473). **Solution** The misconfigured permission was corrected using a simpler and reliable approach that restored the expected communication between components [\[4\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/88574). **Conclusion** No additional preventive actions have been established for now, as this type of failure is inherently difficult to reproduce or validate in non-production environments. A more robust monitoring mechanism for the fix service may be needed to ensure faster detection when similar failures occur. **INFRASTRUCTURE\_ERROR < IMPOSSIBLE\_TO\_TEST**

Read the full incident report →

Started Nov 06, 2025, 03:15 PM UTC· resolved Nov 06, 2025, 04:00 PM UTC

1. identified Nov 06, 2025, 04:08 PM UTC

   A general disruption affected multiple processes within the Essential service, including SAST/SCA machine reattacks, SBOM requests, standalone SCA executions, and our continuous integration (CI) workflows.

2. resolved Nov 06, 2025, 04:21 PM UTC

   The incident has been resolved, and all Essential services are now operating normally.

3. postmortem Nov 06, 2025, 08:52 PM UTC

   **Impact** At least one user observed issues with security scans not completing successfully. The issue started on UTC-5 25-11-06 05:10 and was proactively discovered 5 hours \(TTD\) later by a staff member who noticed that, after a recent update to the database used by our SCA and SBOM scanning processes, an essential data table was missing. This omission caused all automated analyses and reattacks to fail to finish properly. As a result, multiple SCA, SBOM, and SAST jobs were temporarily unable to complete, though no customer reports were received. Approximately 1200 executions across Spots, Labels, and Skims were affected. The problem was resolved in 43.2 minutes \(TTF\), resulting in a total window of exposure of 5.7 hours \(WOE\) [\[1\]](https://gitlab.com/fluidattacks/universe/-/issues/18732). **Cause** During a major update to the internal process that builds the database used by these scans, a required table was accidentally left out from the final version, which caused all jobs depending on it to fail [\[2\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/88049). **Solution** The database generation logic was fixed to include the missing table. A corrected version was generated and deployed manually, restoring normal operation. The change was later merged so that future updates will include this fix automatically [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/88091). **Conclusion** Additional automated tests were added to ensure all required data is present in the database before deployment. Versioning of the database will be implemented to allow faster recovery in case of future issues, and improvements are planned to make the generation process more robust overall. **INCOMPLETE\_PERSPECTIVE < MISSING\_TEST**

Read the full incident report →

Started Nov 06, 2025, 01:26 AM UTC· resolved Nov 06, 2025, 01:33 AM UTC

1. identified Nov 06, 2025, 08:23 PM UTC

   The Fluid Attacks DB portal is experiencing a temporary outage.

2. resolved Nov 06, 2025, 08:24 PM UTC

   The issue has been resolved, and the portal is now fully operational.

3. postmortem Nov 10, 2025, 01:48 PM UTC

   **Impact** At least one user observed that [db.fluidattacks.com](http://db.fluidattacks.com) became temporarily unavailable for a short period. The issue started on UTC-5 25-11-05 19:55 and was proactively discovered 15 minutes \(TTD\) later by a staff member and one of our monitoring tools, which alerted about the service disruption. No customer reports were received. The problem was resolved in 15 minutes \(TTF\), resulting in a total window of exposure of 28.8 minutes \(WOE\) [\[1\]](https://gitlab.com/fluidattacks/universe/-/issues/18637). **Cause** An experimental change was introduced to improve how the service accessed its data. However, this change caused the database application to fail during startup, making it unable to respond to incoming requests [\[2\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/88068). **Solution** The problematic configuration was removed, restoring normal service [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/88070). **Conclusion** Future infrastructure changes will be rolled out gradually using feature flags to minimize potential service disruptions. **INFRASTRUCTURE\_ERROR**

Read the full incident report →

Started Oct 24, 2025, 10:30 PM UTC· resolved Oct 28, 2025, 01:30 AM UTC

1. identified Oct 28, 2025, 03:15 PM UTC

   Users may experience failures when attempting to generate fixes from the platform and through the VS Code and Cursor extensions.

2. identified Oct 28, 2025, 03:16 PM UTC

   We are actively working to resolve the issue and restore full functionality as soon as possible.

3. resolved Oct 28, 2025, 03:17 PM UTC

   The incident has been resolved, and the generation of fixes is now working as expected.

4. postmortem Oct 28, 2025, 07:40 PM UTC

   **Impact** At least one user experienced issues when attempting to generate fixes. The issue started on UTC-5 25-10-21 14:31 and was proactively discovered 3.1 days \(TTD\) later by a staff member who reported through our help desk [\[1\]](https://help.fluidattacks.com/agent/fluid4ttacks/fluid-attacks/tickets/details/944043000051528937) that both Auto Fix and Custom Fix were not working, either from the platform or the IDE extensions. The problem was resolved in 3.1 days \(TTF\), resulting in a total window of exposure of 6.2 days \(WOE\) [\[2\]](https://gitlab.com/fluidattacks/universe/-/issues/18525). **Cause** While updating the internal logic of our Fixes module, a new version of a library responsible for handling connections with AWS services was introduced. This update caused an incompatibility that led to an error preventing the execution of Fixes-related processes. As a result, both the Custom Fix and Suggested Fix features stopped working across the platform and IDE integrations [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/86964). **Solution** The change that caused the incompatibility was reverted, restoring the previous version of the library to recover normal operation of the Fixes module [\[4\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/87454). **Conclusion** We will strengthen our test coverage to detect dependency-related incompatibilities earlier and avoid similar issues in the future. **INCOMPLETE\_PERSPECTIVE < MISSING\_TEST**

Read the full incident report →

Started Oct 23, 2025, 07:16 PM UTC· resolved Oct 23, 2025, 07:17 PM UTC

1. identified Oct 23, 2025, 07:16 PM UTC

   Some Fluid Attacks products are experiencing availability issues. Click for details: https://availability.fluidattacks.com

2. resolved Oct 23, 2025, 07:17 PM UTC

   The incident has been resolved, and all affected services are now fully operational.

3. postmortem Oct 23, 2025, 09:19 PM UTC

   **Impact** An unknown number of internal users found the Fluid Attacks Platform unavailable. The issue started on UTC-5 25-10-21 12:51 and was immediately discovered by one of our monitoring tools, indicating the outage of these components. The problem was resolved in 14.4 minutes \(TTF\), resulting in a total window of exposure of 14.4 minutes \(WOE\). **Cause** A large volume of simultaneous internal processes triggered an unexpected overload in one of our core services, which temporarily degraded its performance and caused a platform outage. The root cause was the number of concurrent requests exceeding the system’s ability to scale quickly. **Solution** We optimized the internal scripts responsible for launching these processes to limit the number of concurrent requests and reduce system load. These changes have already been applied, and further improvements are planned to prevent similar issues in the future. **Conclusion** This incident revealed a scalability limitation in one of our core services. We are working on improvements to make the system more resilient and capable of handling high-demand scenarios without affecting availability. **INFRASTRUCTURE\_ERROR < PERFORMANCE\_DEGRADATION**

Read the full incident report →

Started Oct 23, 2025, 07:08 PM UTC· resolved Oct 23, 2025, 07:55 PM UTC

1. identified Oct 28, 2025, 04:07 PM UTC

   help.fluidattacks.com/portal/en/kb is experiencing accessibility issues. Click for details: https://availability.fluidattacks.com

2. resolved Oct 28, 2025, 04:09 PM UTC

   The incident has been resolved, and help.fluidattacks.com/portal/en/kb is now fully accessible.

3. postmortem Oct 28, 2025, 04:19 PM UTC

   **Impact** At least one user experienced issues accessing the Knowledge Base. The issue started on UTC-5 25-10-23 14:08 and was immediately discovered by one of our monitoring tools, which alerted our team to the unavailability of the site. The problem was resolved in 43.2 minutes \(TTF\), resulting in a total window of exposure of 43.2 minutes \(WOE\) [\[1\]](https://gitlab.com/fluidattacks/universe/-/issues/18482). **Cause** While exploring alternatives to implement redirects from the Knowledge Base to db.fluidattacks.com, to direct references from the KB to the new source of truth, we enabled the Cloudflare proxy. However, Zoho KB is not compatible with Cloudflare’s proxy. As a result, when the site was resolved through the proxy, it failed to load, making the Knowledge Base inaccessible [\[2\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/87119). **Solution** The changes were reverted since it was not possible to configure the intended redirects while using the Cloudflare proxy [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/87173). **Conclusion** After confirming with Zoho Support, we determined that external redirections are not supported. Therefore, only internal redirects within the same Knowledge Base will be implemented going forward. **INCOMPLETE\_PERSPECTIVE**

Read the full incident report →

Started Oct 20, 2025, 02:48 PM UTC· resolved Oct 20, 2025, 11:02 PM UTC

1. identified Oct 20, 2025, 02:48 PM UTC

   An ongoing outage in multiple AWS services is disrupting our platform, the Agent and all API-dependent services. Our engineering team is actively working to mitigate the impact.

2. identified Oct 20, 2025, 11:00 PM UTC

   We are continuing to monitor the incident closely and are actively working to mitigate the impact on our platform and related services.

3. resolved Oct 20, 2025, 11:02 PM UTC

   The incident has been resolved and all our services are now fully operational. AWS services have stabilized, and we are monitoring performance to ensure continued reliability.

4. postmortem Oct 21, 2025, 08:48 PM UTC

   **Impact** Our monitoring tools detected abnormal behavior across all core services, including the platform, agent, and API-dependent components. Although AWS services began experiencing issues at UTC-5 25-10-20 00:11, our platform continued handling requests until approximately UTC-5 25-10-20 09:15 and was proactively discovered 15 minutes \(TTD\) later by one of our monitoring systems, which alerted our team to a service outage affecting several core components. The problem was resolved in 8.4 hours \(TTF\), resulting in a total window of exposure of 8.6 hours \(WOE\). [\[1\]](https://gitlab.com/fluidattacks/universe/-/issues/18386). **Cause** Multiple AWS services experienced a major outage, as reported in the [AWS Health Dashboard](https://health.aws.amazon.com/health/status?path=open-issues). This incident caused disruptions across several AWS components our infrastructure depends on, leading to widespread service failures within Fluid Attacks. **Solution** While AWS services were gradually recovering, our team worked in parallel to implement internal adjustments that allowed our infrastructure to deploy successfully once service stability was restored. These changes focused on ensuring that our components could reconnect, synchronize, and resume normal operation. Most of the downtime corresponded to AWS’s recovery period, followed by an additional time during which we completed the internal redeployment process. **Conclusion** We are actively working on migrating to more self-contained infrastructure stacks to reduce dependency-related issues and improve the overall reliability and reproducibility of our services. **THIRD\_PARTY\_ERROR**

Read the full incident report →

Started Oct 08, 2025, 06:38 PM UTC· resolved Oct 08, 2025, 08:43 PM UTC

1. identified Oct 08, 2025, 06:38 PM UTC

   Users are experiencing issues when attempting to export the Vulnerabilities CSV file. The process fails to complete, preventing the report generation.

2. resolved Oct 08, 2025, 08:43 PM UTC

   The incident has been resolved, and the vulnerabilities CSV export feature is now working correctly.

3. postmortem Oct 08, 2025, 10:56 PM UTC

   **Impact** At least one user experienced issues when trying to generate a Vulnerabilities CSV report. The issue started on UTC-5 25-10-07 17:54 and was reactively discovered 17.5 hours \(TTD\) later by a client who reported through our help desk [\[1\]](https://help.fluidattacks.com/agent/fluid4ttacks/fluid-attacks/tickets/details/944043000049838507) that the process stayed stuck in a “Processing file” state and never finished. This issue affected all groups that had vulnerabilities marked with the source `CUSTOMER`. The problem was resolved in 2.6 hours \(TTF\), resulting in a total window of exposure of 20.1 hours \(WOE\) [\[2\]](https://gitlab.com/fluidattacks/universe/-/issues/18219). **Cause** A specific value called `CUSTOMER` was removed from the system configuration used to identify the source of vulnerabilities. This value was deleted as part of a cleanup process, assuming it was no longer needed. However, the platform still had some vulnerabilities using that value, and a function tried to read it when generating the CSV report. Since the value no longer existed, the process failed and caused the file generation to stop [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/86156/diffs). **Solution** The `CUSTOMER` value was temporarily added back to the system so reports could be generated correctly again. A migration will be done soon to remove all vulnerabilities using this outdated value, allowing it to be safely deleted later [\[4\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/86219/diffs). **Conclusion** Extra checks were added to ensure that all possible source values are correctly recognized by the system. This will prevent similar errors in future updates or cleanups. **INCOMPLETE\_PERSPECTIVE < MISSING\_TEST**

Read the full incident report →

Started Oct 06, 2025, 02:11 PM UTC· resolved Oct 06, 2025, 03:22 PM UTC

1. identified Oct 06, 2025, 02:11 PM UTC

   It has been observed that when accessing SCA findings, the platform displays a blank screen.

2. resolved Oct 06, 2025, 03:22 PM UTC

   The incident has been resolved, and findings now load and display correctly.

3. postmortem Oct 07, 2025, 04:16 PM UTC

   **Impact** At least three users experienced a blank screen issue when accessing certain vulnerabilities. The issue started on UTC-5 25-10-03 23:52 and was reactively discovered 1.8 days \(TTD\) later by a customer who reported through our help desk [\[1\]](https://help.fluidattacks.com/agent/fluid4ttacks/fluid-attacks/tickets/details/944043000049381865) that it was not possible to access some Weaknesses. These weaknesses were linked to vulnerabilities reported under SCA, and every organization or group with weaknesses associated with SCA vulnerabilities was affected. No other modules in the platform were impacted. The problem was resolved in 13.4 hours \(TTF\), resulting in a total window of exposure of 2.3 days \(WOE\) [\[2\]](https://gitlab.com/fluidattacks/universe/-/issues/18163). **Cause** A field that was previously used to display vulnerability information in the application was removed from the system’s API, but the platform’s interface was still trying to access it. This mismatch caused an error when loading certain weaknesses, which resulted in a blank screen [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/85968). **Solution** The platform was updated to stop using the removed field and to retrieve the necessary vulnerability data from the correct source. This change ensures that all information loads properly and prevents similar display errors in the future [\[4\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/85978). **Conclusion** In addition to discussing refactoring plans to prevent similar issues, the team agreed to implement a stricter validation process, ensuring that frontend dependencies are reviewed and adjusted before backend field removals. This will enhance communication and prevent similar disruptions in future releases. **UNHANDLED\_EXCEPTION <** **INFRASTRUCTURE\_ERROR**

Read the full incident report →

Started Sep 26, 2025, 06:00 AM UTC· resolved Sep 26, 2025, 06:30 AM UTC

1. identified Sep 26, 2025, 01:18 PM UTC

   Some Fluid Attacks products are experiencing availability issues. Click for details: https://availability.fluidattacks.com

2. resolved Sep 26, 2025, 01:20 PM UTC

   The issue has been resolved, and all Fluid Attacks products are now fully available.

3. postmortem Sep 26, 2025, 02:36 PM UTC

   **Impact** An unknown number of users encountered the Fluid Attacks' official documentation, which was unavailable. The issue started on UTC-5 25-09-26 00:45 and was proactively discovered 5 minutes \(TTD\) later by one of our monitoring tools and staff members, indicating a disruption in this component. The problem was resolved in 1.2 hours \(TTF\), resulting in a total window of exposure of 1.2 hours \(WOE\) [\[1\]](https://gitlab.com/fluidattacks/universe/-/issues/18036). **Cause** A system update introduced a change that reduced the limit on certain network connections. This prevented part of our infrastructure from communicating properly, which led to the disruption [\[2\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/85382). **Solution** We updated the configuration to allow the affected component to connect directly, restoring normal communication and service availability [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/85392). **Conclusion** To reduce the risk of similar problems in the future, we will adopt a safer process when updating critical systems by gradually migrating services to a duplicate environment. While this makes updates slower, it helps prevent disruptions that may only appear hours after a change. We will also continue to explore additional preventive measures. **INFRASTRUCTURE\_ERROR < IMPOSSIBLE\_TO\_TEST**

Read the full incident report →

Started Sep 25, 2025, 06:26 PM UTC· resolved Sep 25, 2025, 06:53 PM UTC

1. identified Sep 25, 2025, 06:41 PM UTC

   While navigating the platform, the screen remains blank, blocking normal navigation and use.

2. resolved Sep 25, 2025, 06:53 PM UTC

   The incident has been resolved, and the platform is now working normally, allowing users to navigate without interruptions.

3. postmortem Sep 25, 2025, 09:44 PM UTC

   **Impact** At least one user experienced problems when navigating or accessing the platform. The issue started on UTC-5 25-09-25 13:08 and was proactively discovered 14.4 minutes \(TTD\) later by a staff member who reported through our internal chats that the screen stayed blank, making it impossible to use. The problem was resolved in 14.4 minutes \(TTF\), resulting in a total window of exposure of 28.8 minutes \(WOE\).. **Cause** During a system update, an important setting that allows the platform to be displayed was removed by mistake. This caused the platform’s main page to stop loading [\[1\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/85334). **Solution** The setting was restored, which immediately allowed the platform to load and work normally again. **Conclusion** Additional safeguards will be implemented in our update process to prevent this type of error from happening again. **INFRASTRUCTURE\_ERROR**

Read the full incident report →

Started Sep 12, 2025, 11:30 PM UTC· resolved Oct 07, 2025, 07:00 PM UTC

1. identified Oct 10, 2025, 03:51 PM UTC

   Integrations such as GitLab, Azure DevOps, and Google Chat experienced issues where automated notifications for newly detected vulnerabilities were not delivered.

2. resolved Oct 10, 2025, 03:54 PM UTC

   The incident has been resolved, and automatic vulnerability notifications through the integrations are now working as expected.

3. postmortem Oct 10, 2025, 04:07 PM UTC

   **Impact** At least one internal user identified that vulnerability notifications were not being received. The issue started on UTC-5 25-09-11 18:56 and was proactively discovered 23.2 hours \(TTD\) later by a staff member, who noticed that the automatic notifications and ticket creation for new vulnerabilities had stopped working in Azure DevOps, Webhooks, GitLab, and Google Chat. Up to 134 organizations could have been affected, although no client reports were received. The problem was resolved in 24.8 days \(TTF\), resulting in a total window of exposure of 25.7 days \(WOE\) [\[1\]](https://gitlab.com/fluidattacks/universe/-/issues/17854). **Cause** The system was checking for a specific data field that many vulnerabilities did not include. Because of this, if even one vulnerability didn’t have that field, the entire notification process stopped, and no alerts were sent. **Solution** The process to utilize a data field that is always present was modified. Notifications are sent even if some vulnerabilities are missing optional data [\[2\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/86117). **Conclusion** The notification system is now working again for all integrations, ensuring that users are properly alerted about new vulnerabilities. Additional safeguards are being evaluated, including new validation steps, to ensure this type of issue does not occur again in the future. **INCOMPLETE\_PERSPECTIVE < MISSING\_ALERT**

Read the full incident report →

Started Sep 05, 2025, 03:53 AM UTC· resolved Sep 05, 2025, 11:45 AM UTC

1. identified Sep 08, 2025, 02:04 PM UTC

   Some Fluid Attacks products are experiencing availability issues. Click for details: https://availability.fluidattacks.com

2. resolved Sep 08, 2025, 02:05 PM UTC

   The issue has been resolved, and all Fluid Attacks products are now fully available.

3. postmortem Sep 08, 2025, 02:23 PM UTC

   **Impact** At least one user observed disruptions across multiple features. The issue started on UTC-5 25-09-04 21:52 and was proactively discovered 43.2 minutes \(TTD\) later by a staff member who noticed that GitLab pipeline jobs began to fail. This quickly escalated: the Fluid Agent and API became unavailable, and eventually the entire platform went down. As a result, data processing tasks \(ETLs\) were delayed, affecting internal analytics and billing. The scanning system failed to update its database and could not process new scans. Platform queues were frozen, blocking reports, reattacks, and cloning. Additionally, downloadable technical and executive reports could not be generated. Overall, the Agent, API, Scanner, and Platform were all impacted. However, since this occurred outside of business hours, no clients were affected and no external reports were generated. The problem was resolved in 7.9 hours \(TTF\), resulting in a total window of exposure of 8.6 hours \(WOE\). **Cause** During an infrastructure update, some permissions were removed before new permissions were applied. This left the system without the necessary authorizations to continue the update, which caused critical services to stop working [\[1\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/84049). **Solution** The missing permissions were restored, and the update was re-applied manually, which corrected most of the issues. Some configurations were out of sync with the real environment, so they were cleaned up and recreated to bring the system back into alignment. After these actions, all affected services were restored. **Conclusion** We are evaluating safeguards so that future infrastructure updates can detect these kinds of conflicts in advance and raise a clear error, preventing critical permissions from being removed and avoiding system downtime. **INFRASTRUCTURE\_ERROR < INCOMPLETE\_PERSPECTIVE**

Read the full incident report →

Started Aug 31, 2025, 09:45 PM UTC· resolved Sep 01, 2025, 03:30 PM UTC

1. identified Sep 18, 2025, 09:46 PM UTC

   An error caused inconsistencies in the author counting process.

2. resolved Sep 18, 2025, 09:47 PM UTC

   The incident has been resolved, and the author counting process is now working correctly.

3. postmortem Sep 18, 2025, 09:48 PM UTC

   **Impact** At least one user experienced inconsistencies in the registration of commit authors. The issue started on UTC-5 25-08-29 17:29 and was reactively discovered 1.9 days \(TTD\) later by a client who reported through our help desk that the platform was showing commit authors in September, even though those authors had not made commits during that month. All groups with active Advanced subscriptions during August and September, along with their respective organizations, were affected. The problem was resolved in 17.2 hours \(TTF\), resulting in a total window of exposure of 2.6 days \(WOE\) [\[1\]](https://gitlab.com/fluidattacks/universe/-/issues/17669). **Cause** During the transition to a new version of the system used to run daily jobs, the process that records commit authors stopped working for three days at the end of August. When it was fixed on September 1, the system mistakenly registered the missing authors from August as if they had been committed in September [\[2\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/83644). **Solution** The job configuration was updated to use the correct version of the system, which resolved the compatibility problem and allowed the daily registration process to work properly again [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/83673). **Conclusion** We are reviewing ways to make these jobs more robust, including adding alerts that notify us when the number of authors recorded for a given day is lower than expected, so similar issues can be detected sooner. **DATA\_QUALITY < MISSING\_ALERT**

Read the full incident report →

Started Aug 19, 2025, 10:04 PM UTC· resolved Aug 20, 2025, 01:13 PM UTC

1. identified Aug 19, 2025, 10:04 PM UTC

   Scheduled tasks, including reattack request, report generation, and other processes, are not being executed, leading to disruptions in expected workflows.

2. resolved Aug 20, 2025, 10:37 PM UTC

   The incident has been resolved, and scheduled tasks are now running as expected.

Read the full incident report →

Started Jul 23, 2025, 11:15 PM UTC· resolved Jul 24, 2025, 01:12 AM UTC

1. identified Aug 11, 2025, 10:02 PM UTC

   It was identified that a permission misconfiguration is preventing a user from accessing the platform, displaying an Access denied message.

2. resolved Aug 11, 2025, 10:04 PM UTC

   The incident has been resolved, and now platform access has been fully restored.

3. postmortem Aug 11, 2025, 10:06 PM UTC

   **Impact** At least one user experienced difficulties accessing the platform. The issue started on UTC-5 25-06-27 15:55 and was reactively discovered 26 days \(TTD\) later by a client who reported through our help desk [\[1\]](https://help.fluidattacks.com/agent/fluid4ttacks/fluid-attacks/tickets/details/944043000042595654) that the platform displayed an `Access denied` message when trying to access the platform. The problem was resolved in 5.2 hours \(TTF\), resulting in a total window of exposure of 26.2 days \(WOE\) [\[2\]](https://gitlab.com/fluidattacks/universe/-/issues/17099). **Cause** During a system update to improve security, some of the general user permissions were not fully updated. As a result, all users with similar roles were missing certain permissions needed to access specific features, which prevented platform access [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/80075). **Solution** The missing permissions were added to the `User` role, restoring access to the platform. In this case, three specific access permissions were granted [\[4\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/81612). **Conclusion** The incident highlights the importance of reviewing and updating general permission settings during system changes to ensure that all users retain access to the needed features. **FAILED\_MIGRATION < INCOMPLETE\_PERSPECTIVE**

Read the full incident report →

Started Jul 23, 2025, 11:02 PM UTC· resolved Jul 24, 2025, 02:15 AM UTC

1. identified Jul 23, 2025, 11:02 PM UTC

   Users trying to access the platform through BitBucket are unable to log in due to a redirect URI issue.

2. identified Jul 24, 2025, 01:12 PM UTC

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

3. resolved Jul 24, 2025, 01:39 PM UTC

   The incident has been resolved, and access via BitBucket authentication is now working properly.

4. postmortem Jul 24, 2025, 11:18 PM UTC

   **Impact** At least one user experienced problems accessing the platform. The issue started on UTC-5 25-07-23 15:14 and was reactively discovered 1.2 hours \(TTD\) later by a client who reported through our help desk [\[1\]](https://help.fluidattacks.com/agent/fluid4ttacks/fluid-attacks/tickets/details/944043000042602825) that, when trying to log in, an `Invalid redirect_uri` error was displayed, preventing access. No other modules or users not using Bitbucket for login were affected. The problem was resolved in 2.1 hours \(TTF\), resulting in a total window of exposure of 3.3 hours \(WOE\) [\[2\]](https://gitlab.com/fluidattacks/universe/-/issues/17096). **Cause** The problem was caused by a change in the redirect URL used for login. Specifically, an alias was added to the Bitbucket callback configuration in the production environment, which affected users logging in through Bitbucket. **Solution** The tokens for Bitbucket authentication were rotated again, both in the development and production environments, to restore proper access [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/81599). **Conclusion** The platform is now working as expected for users logging in via Bitbucket. This incident highlights the importance of validating configuration changes before deploying to production, especially those related to authentication. **ROTATION\_FAILURE < INCOMPLETE\_PERSPECTIVE**

Read the full incident report →