Is Fluid Attacks down?

The analytics charts (by group, by organization, and portfolio views) are currently displaying outdated information. The data behind these charts last refreshed on 2026-06-24 and has not updated since, so recent activity, including groups and repositories created after that date, is not yet reflected. This issue is limited to the charts only: the underlying data remains complete, intact, and unaffected, and there is no impact to security or to any other part of the platform. Our team is actively investigating the cause and working to restore regular chart updates. Further updates will be posted as we make progress.

This incident has been resolved.

### Postmortem ### Impact Users experienced stale analytics charts across the platform: the documents powering the "by group", "by organization", and "portfolio" views stopped being refreshed, leaving the vast majority of organizations displaying outdated data as of June 24. Groups and repositories created after that date did not appear in the charts even when data was available. The issue started on June 23, 2026 and was discovered approximately 20 days later by a staff member who noticed the charts were not up to date. Once identified, the problem was fully resolved within 1 day. ### Cause A scheduled background job responsible for regenerating analytics charts was failing silently. When processing a large number of organizations, a single error during the generation of one organization's charts caused the entire job to stop, preventing all remaining organizations from being updated. Over time, increased load on the platform's data layer began triggering these errors more frequently and across more organizations, amplifying the impact. Because no alerts were configured to notify the team when this job failed, the issue went undetected for several weeks. ### Solution The chart generation process was updated to handle errors on a per-organization basis: if one organization's charts fail to generate, it is logged and skipped, and processing continues for all others. Additional safeguards were introduced to reduce pressure on the underlying data layer during high-load periods. Alerting was also configured so that failures in this job are now immediately surfaced to the engineering team, preventing similar silent failures in the future. ### Conclusion A background job with no error isolation and no failure alerting can silently affect customer-facing data for an extended period before anyone notices. The key improvements, isolating errors per subject and adding alerts on job failures, ensure this class of issue will be detected and addressed much faster going forward. We apologize for the disruption and are committed to maintaining the accuracy and freshness of your analytics data.

Some groups are receiving unexpected open events related to environment URL availability. These events were generated incorrectly and do not reflect actual issues in the affected groups. Our team is investigating and working on a fix.

This incident has been resolved.

### Postmortem #### Impact At least one user experienced a flood of false-positive `ENVIRONMENT_ISSUES` events on their production groups, each dispatching an automatic email notification, for URL environments that were in fact reachable. The issue started on 2026-07-08 at 20:00 \(UTC-5\) and was reactively discovered 14.9 hours later by a staff member who noticed an unusually high volume of events of this type opened simultaneously across multiple production groups, all sharing an identical "URL is not reachable" description. The problem was resolved within an additional 2.6 hours, resulting in a total window of exposure of 17.5 hours. #### Cause A new URL environment connectivity check ran for the first time in production on its automated schedule. The logic that determines which URLs are eligible for the check contained a flaw: instead of correctly excluding URLs that require authentication or that are only reachable through special network channels, it included them in an unauthenticated probe. Upon receiving unauthorized-access responses, such as redirects to login portals, the system incorrectly classified those URLs as unreachable and opened an incident event for each one, also dispatching a notification email to the group's stakeholders. The affected URLs were fully functional; they simply required credentials that the automated probe never supplied. Approximately 850 spurious events were created across production groups. #### Solution The approximately 850 incorrectly generated events were closed through an automated process that identified them by type, description, and creation time, and closed them directly without emitting further notification emails to users. The automated scheduler was disabled to prevent the issue from recurring. As a permanent fix, the connectivity check will no longer run automatically and will instead become an on-demand action that internal users can trigger manually from the interface. Additionally, the eligibility logic will be corrected to properly exclude authenticated environments and those operating through special network channels, and an exhaustive dry-run against real production data will be required before any re-enablement. #### Conclusion This incident revealed that the URL eligibility logic and the handling of authenticated environments were never validated end-to-end before the first production run, allowing an unauthenticated probe to be misread as a connectivity failure at scale. Tests covering the eligibility logic and the authenticated-URL flow, along with a dry-run against real production data before enabling any automated task, would have prevented these events from being created. **MISSING\_TEST < INCOMPLETE\_PERSPECTIVE**

An issue was found in FIXES-CODE. Click for details: https://availability.fluidattacks.com

This incident has been resolved.

Users may experience an unexpected error when accessing the Evidence page. The application fails to load due to a null reference issue while processing evidence data. Our team is investigating and working on a fix.

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

A fix has been implemented and we are monitoring the results.

The issue causing the Evidence page to crash has been identified and resolved. The page is now loading correctly for all users. We apologize for the disruption and appreciate your patience while we worked through it.

## Impact All users on the platform experienced the inability to view or upload evidence on finding pages for approximately 58 minutes. Both the web interface and the desktop application were affected. Users without access to certain findings were additionally stuck in a reload loop during the same window. The issue started on UTC-5 26-05-26 14:35 and was proactively discovered 57.6 minutes \(TTD\) later by a staff member who noticed that evidence data was not loading and alerted the team. The problem was resolved in 57.6 minutes \(TTF\), resulting in a total window of exposure of 1.9 hours \(WOE\). ## Cause A planned dependency upgrade deployed to remediate reported security vulnerabilities introduced an undocumented behavioral change in a core library responsible for mapping GraphQL field names to their internal data keys. Under the previous version, fields whose names were entirely lowercase were left unchanged during this mapping. Under the upgraded version, all fields, regardless of casing were passed through a name converter that inserts underscores before numeric characters. As a result, fields such as those used to store evidence items were silently redirected to keys that did not exist in the underlying data, causing them to return empty values instead of their content. The behavioral change was documented in the library's internal pull request history but was not prominently surfaced in the official changelog, and the existing test suite did not cover the full name-resolution flow against a live schema. ## Solution An emergency rollback to the previous dependency versions was deployed the same day, restoring all affected functionality within the incident window. A definitive fix was subsequently developed and deployed two days later: the dependency upgrade was re-applied alongside a custom name-mapping configuration that preserves the correct resolution behavior for all-lowercase field names while still applying the standard conversion to mixed-case names. Automated tests were added to explicitly validate that all numbered evidence fields resolve to their expected values, preventing silent regressions of this class in future dependency upgrades. ## Conclusion Major-version upgrades to core GraphQL infrastructure libraries must be accompanied by integration tests that exercise the full field-name resolution pipeline against a real executable schema not only unit tests of business logic. The failure was silent by design: fields returned empty values without raising errors, making it indistinguishable from missing data until users reported it. Future upgrades to schema-handling libraries require an explicit end-to-end assertion that no field resolves to null when data is present. **THIRD\_PARTY\_CHANGE < MISSING\_TEST < INCOMPLETE\_PERSPECTIVE**

An issue was found in DOCS. Click for details: https://availability.fluidattacks.com

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

This incident has been resolved.

## Impact On May 20, 2026, users visiting [docs.fluidattacks.com](http://docs.fluidattacks.com/) may have encountered a "Server failed to respond" error for approximately 1.3 hours. The issue was detected internally by our team and resolved within the same window. ## What happened During a routine deployment operation, an outdated version of the documentation service was accidentally restored to production. This older version was missing a configuration component required for the service to start up correctly, which caused the site to become unavailable. Think of it like accidentally restoring an old backup that was missing a key setting the service came back up in an incomplete state and was unable to respond to requests. ## What we changed Service was restored by redeploying the latest stable version of the documentation site, bringing `docs.fluidattacks.com` back online. We then applied a permanent fix to ensure the required configuration is always present and correctly loaded when the service starts, preventing the same failure mode from recurring. ## Going forward We have updated our deployment process to prevent outdated versions from being restored to production. Safeguards are now in place to ensure that only verified, fully configured versions of the service can be deployed. **COMMUNICATION\_FAILURE < INCOMPLETE\_PERSPECTIVE.**