Status page
Last updated: Jun 5, 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 and Europe every minute for all applications. 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.
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