Fluid Attacks Outage History
Fluid Attacks is up right nowPingoru has recorded 69 incidents for Fluid Attacks: 54 in the last 12 months and 22 in the last 90 days.
Show as a table
| Month | Incidents | Hours with an open incident |
|---|---|---|
| April 2026 | 2 | 0 of 720 (0%) |
| May 2026 | 6 | 6 of 744 (1%) |
| June 2026 | 1 | 2 of 720 (0%) |
| July 2026 | 2 | 28 of 744 (4%) |
| August 2026 | 7 | 63 of 744 (8%) |
| September 2026 | 10 | 82 of 720 (11%) |
| October 2026 | 5 | 11 of 565 (2%) |
Incidents, newest first
Notice July 14, 2025 Delayed listing of reattack requests 1d 6h Platform
Started Jul 14, 2025, 03:40 PM UTC· resolved Jul 15, 2025, 09:54 PM UTC
- identified Jul 14, 2025, 03:40 PM UTC
It was identified that reattack requests are not being listed for review immediately after submission. Instead, they appear gradually over time, affecting their timely visibility and reducing the response window for the team, potentially impacting SLA commitments.
- resolved Jul 15, 2025, 09:54 PM UTC
The incident has been resolved, and reattack requests are now being listed as expected, restoring the normal workflow for affected users.
- postmortem Jul 16, 2025, 01:54 PM UTC
**Impact** At least 17 groups across 7 organizations experienced issues where some reattack requests were not being displayed in the **To Do** section under **Reattacks**. The issue started on UTC-5 25-07-10 17:30 and was proactively discovered 1 day \(TTD\) later by a staff member who reported through our help desk that [\[1\]](https://help.fluidattacks.com/agent/fluid4ttacks/fluid-attacks/tickets/details/944043000041310063) expected reattack entries were missing. As a result, these reattacks were not visible to the team, preventing their review and verification within the expected time frame. The impact was limited to the Reattacks section of the To Do view, and no other component or functionality was affected. The problem was resolved in 3.8 days \(TTF\), resulting in a total window of exposure of 4.8 days \(WOE\) [\[2\]](https://gitlab.com/fluidattacks/universe/-/issues/16895). **Cause** The component in charge of preparing the information used to show pending reattacks became unstable due to a configuration that was not adequate for the volume of data being processed. This caused delays and failures that prevented some reattacks from being included in the list during that time. **Solution** The platform was updated to obtain reattack information from a more direct and reliable source, avoiding dependence on the unstable component. This ensures that pending reattacks are listed as expected [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/80990),[\[4\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/81012). **Conclusion** The way pending reattacks are listed was improved to prevent similar issues in the future, especially in scenarios with high activity. Monitoring will also be strengthened for background processes that manage this type of data to ensure better stability and visibility across the platform. **INFRASTRUCTURE\_ERROR < INCOMPLETE\_PERSPECTIVE**
Notice July 11, 2025 Vulnerabilities incorrectly reverted to Submitted state 17h 46m Platform
Started Jul 11, 2025, 01:53 AM UTC· resolved Jul 11, 2025, 07:40 PM UTC
- identified Jul 11, 2025, 01:53 AM UTC
Vulnerabilities that were previously reported are being mistakenly shown as "Submitted", disrupting their expected workflow.
- resolved Jul 11, 2025, 07:40 PM UTC
The incident has been resolved, and vulnerabilities now display their correct status.
- postmortem Jul 14, 2025, 12:47 PM UTC
**Impact** Three groups experienced inconsistencies in vulnerability statuses and reporting. The issue started on UTC-5 25-07-08 19:40 and was proactively discovered 14.8 hours \(TTD\) later by a staff member, who reported through our help desk [\[1\]](https://help.fluidattacks.com/agent/fluid4ttacks/fluid-attacks/tickets/details/944043000040982204) that some vulnerabilities that should have been marked as `Vulnerable` were not being reported to clients because their status had incorrectly changed to `Submitted.` This incident affected only the metadata of the vulnerabilities and the metrics of related findings, both at the database level, in API responses, and in how the information was displayed on the platform. The problem was resolved in 2.2 days \(TTF\), resulting in a total window of exposure of 2.9 days \(WOE\) [\[2\]](https://gitlab.com/fluidattacks/universe/-/issues/16826). **Cause** The issue surfaced after a migration was executed [\[3\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/80792). However, complications had already been introduced earlier with the implementation of a new table in DynamoDB to store issue history [\[4\]](https://gitlab.com/fluidattacks/universe/-/issues/9579). To temporarily address data linkage issues, multiple sources were used to populate vulnerability history. The historical data was migrated to the destination table [\[5\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/56327), but due to ongoing inconsistencies, data was being saved in two places. This dual-source approach led to conflicting information and caused some vulnerabilities to display the incorrect statuses. **Solution** A corrective migration was developed and executed to locate and fix the affected records, restoring the appropriate status for the vulnerabilities [\[6\]](https://gitlab.com/fluidattacks/universe/-/merge_requests/80848). **Conclusion** We are moving forward with the implementation of a single, unified data source for vulnerability history. This will reduce complexity, eliminate inconsistencies, and improve the reliability of status reporting across the system. **FAILED\_MIGRATION < DATA\_QUALITY < INCOMPLETE\_PERSPECTIVE**