Fluid Attacks policy on showing the status of services | Fluid Attacks

Status Page

We continuously monitor our components:

  1. Platform
  2. Web
  3. Docs
  4. Agent
  5. Cloning
  6. Scanning
  7. Extensions
  8. Mailing
  9. Dependencies
In doing so, we let all interested parties, including our developers, know the availability status of such 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 Fluid Attacks creates, updates or resolves an incident.

Requirements

  1. 075. Record exceptional events in logs

Public Incidents

Transparency is a fundamental value in our company, and we are proud to offer our users a clear view of our services. In this section, we will show you how our incident template is composed, where you will know what kind of information we collect about issues that may occur on our components.

The template is composed of the following sections:

Impact

  1. Affected users: the total number of users reporting the same incident or related problems.
  2. Start time and End time: the date and time when the incident reached the production environment and when the case was closed.
  3. Detection Time: the date and time the first report arrived.
  4. Time to recover: the total time it took to resolve the case from reporting to closing.
  5. Time to detect: the total time it took to catch the problem from reaching the production environment to the first report.
  6. Discovering: how it was discovered, proactively (by a client) or reactively (by staff members).
  7. Description: how it impacted or negatively affected users.

Cause

  1. Reason: the initial "why" behind the incident, this section delves into the fundamental factors or triggers that led to the problem.
  2. Merge Request: the URL of the merge request that introduced the problem.

Solution

  1. Remediation: the solution the developer in charge applies to solve this incident.
  2. Merge Request: the URL of the merge request that fixed the issue.

Conclusion

  1. Learning Obtained: insights gained during the incident resolution process.
  2. Root Cause: factors contributing to the incident reaching the production environment.
  3. Preventive Measures: actions or strategies the team is implementing to avoid similar issues in the future.
  4. Taxonomy Term: the term used to summarize and categorize the incident by its root cause.

Incident History

This page functions as 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

This page serves as a detailed record of our services' availability history. Users can conveniently filter information by component and month, providing a clear visualization of uptime and related events for those interested. Access to the site is available via status.fluidattacks.com/uptime.