Status page

Last updated: Nov 4, 2026

Fluid Attacks continuously monitors these components:

Platform
Web
Docs
Agent (CI Gate)
API
Criteria (vulnerability database)
Integrations
Cloning
Scanning
Extensions
Mailing
Dependencies

Thus, Fluid Attacks tells all the interested parties, including its developers, the availability status of those systems. Servers in North America, South America, Europe, and Asia run the monitoring checks. The frequencies of these checks are from every ten seconds for the platform API to every ten minutes for the public websites. This information is real-time and available on the Status page of Fluid Attacks. Anybody can subscribe to get notifications by email, Slack, or RSS when Fluid Attacks creates, updates, or resolves an incident.

Service states

Each component on the Status page has one of three states.

Operational. The component answered the checks correctly and in the expected response time.

Degraded performance. The component answered correctly and returned the data that the checks ask for, but its response time was longer than the limit. In this state, all the functionalities continue to operate. The component continues to serve requests, and most users do not see a difference.

Only the third-party components in the Dependencies group show this state, in accordance with the status that the vendors publish. When a check of a Fluid Attacks component is slow, the team gets only an email notification. The component on the Status page stays operational, and no public incident opens.

Major outage. The component failed the checks. It did not answer, answered with an error, or did not answer before the maximum wait time. This state opens a public incident and sends notifications to the subscribers.

Public incidents

Transparency is a fundamental value of Fluid Attacks. Fluid Attacks is proud to give its users a clear status of its services.

This is the structure of the incident template of Fluid Attacks. It shows the information that Fluid Attacks collects about the issues that can occur on its components.

Impact

Affected users: The total number of users that report the same incident or related problems
Start time and End time: The date and time when the incident got to the production environment, and when the case was closed
Detection time: The date and time when the first report arrived
Time to recover: The total time to resolve the case, from the report to the closure
Time to detect: The total time to find the problem, from when it got to the production environment to the first report
Discovering: How Fluid Attacks found the incident: proactively (by staff members) or reactively (by a client)
Description: How the incident affected users

Cause

Reason: The initial "why" of the incident. This section describes the fundamental factors or triggers that caused the problem.
Merge request: The URL of the merge request that introduced the problem

Solution

Remediation: The solution that the developer in charge applied to resolve the incident
Merge request: The URL of the merge request that fixed the issue

Conclusion

Learning obtained: The lessons learned during the incident resolution process
Root cause: The factors that let the incident get to the production environment
Preventive measures: The actions or strategies that Fluid Attacks implements to prevent similar issues in the future
Taxonomy term: The term that summarizes and categorizes the incident by its root cause

Incident history

The Incidents page is a full record of each incident. It gives detailed descriptions with the structure above. The record is available at status.fluidattacks.com/history.

Uptime history

The Uptime page is a detailed record of the availability history of the services of Fluid Attacks. Users can easily filter the information by component and time period. The page shows uptime and related events clearly. This page is status.fluidattacks.com/uptime.

Requirement

This Fluid Attacks requirement applies to the controls on this page:

075. Record exceptional events in logs