Status page
Last updated: Sep 23, 2026
We continuously monitor our components:
In doing so, we let all interested parties, including our developers, know the availability status of those systems. Monitoring checks are run on servers in North America, South America, Europe and Asia, at frequencies ranging from every ten seconds for our platform API to every ten minutes for our public websites. This information is real-time and available on our Status page. Anyone can subscribe to receive notifications via email, Slack or RSS whenever we create, update or resolve an incident.
Service states
Each component on our Status page carries one of three states.
Operational. The component answered our checks correctly and within the response time we expect.
Degraded performance. The component answered correctly, returning the data our checks ask for, but took longer than the response time we consider acceptable. No functionality is lost in this state: requests are still served, and most users notice nothing. We surface it because sustained slowness is often the first visible sign of a problem that has not yet become an outage. A degraded component does not open a public incident, and it returns to operational on its own once response times recover.
Major outage. The component failed our checks: it did not answer, answered with an error, or exceeded the time after which we stop waiting. This is the state that opens a public incident and notifies our subscribers.
Public incidents
Transparency is a fundamental value in our company, and we are proud to offer our users a clear status of our services.
Below is how our incident template is composed, specifying what kind of information we collect about issues that may occur on our components.
Impact
- Affected users: The total number of users reporting the same incident or related problems
- Start time and End time: Rhe date and time when the incident reached the production environment and when the case was closed
- Detection time: Rhe date and time the first report arrived
- Time to recover: The total time it took to resolve the case from reporting to closing
- Time to detect: The total time it took to catch the problem from reaching the production environment to the first report
- Discovering: How the incident was discovered, whether proactively (by a client) or reactively (by staff members)
- Description: How the incident impacted or negatively affected users
Cause
- Reason: The initial "why" behind the incident; this section delves into the fundamental factors or triggers that led to the problem
- Merge request: The URL of the merge request that introduced the problem
Solution
- Remediation: The solution the developer in charge applied to solve this incident
- Merge request: The URL of the merge request that fixed the issue
Conclusion
- Learning obtained: Insights gained during the incident resolution process
- Root cause: Factors contributing to the incident reaching the production environment
- Preventive measures: Actions or strategies we are implementing to avoid similar issues in the future
- Taxonomy term: The term used to summarize and categorize the incident by its root cause
Incident history
The Incidents page is a comprehensive record detailing each incident encountered, providing in-depth descriptions following the structure outlined above. Those interested can access this log at status.fluidattacks.com/history.
Uptime history
The Uptime page serves as a detailed record of our services' availability history. Users can conveniently filter information by component and time period, providing a clear visualization of uptime and related events to those interested. This page is status.fluidattacks.com/uptime.
Requirement
The following Fluid Attacks requirement applies to the controls described on this page:
075. Record exceptional events in logs