--- service: "Fluid Attacks" status: "up" reports_last_hour: 0 reports_last_12_hours: 0 baseline_reports_per_hour: 0 checked_at: "2026-10-31T19:36:14.209Z" url: "https://instatus.com/now/fluidattacks.com" official_status_page: "https://status.fluidattacks.com" website: "https://fluidattacks.com" --- # Is Fluid Attacks down? No, it's up. 0 reports in the last hour. ## Official updates - **MCP Server, AI Chat and PR Assistant Unavailable** (RESOLVED, 2026-10-26T23:01:37.000Z): ### Postmortem #### Impact Some users experienced an outage of the AI-powered services on our platform: the AI agent chat failed with "Failed to connect to chat service", sessions from external MCP clients could not start, and some pull request reviews from the PR Assistant did not finish processing. The issue started on UTC-5 26-10-26 11:35 and was reactively discovered 5.8 hours \(TTD\) later by a staff member who noticed that the AI agent had stopped responding. The problem was resolved in 1.2 hours \(TTF\), resulting in a total window of exposure of 7 hours \(WOE\). * **AI Agent**: users who opened the AI agent on the platform did not get an answer. * **MCP server**: connections from MCP clients such as Claude Desktop, Claude Code and IDEs failed with "Unexpected content type: text/html". * **PR Assistant**: some pull request review runs never finished processing. * **Scope**: the API, vulnerability management, reports and scans kept working normally, and no data was lost or exposed. #### Cause The services inside our infrastructure locate each other through an internal name resolution service. A change that enabled a new network security layer on some groups of servers modified how name resolution works on those servers[.](https://gitlab.com/fluidattacks/universe/-/merge_requests/118341) On those servers the internal name resolution service ended up forwarding requests to itself, detected the loop, and stopped. Nothing restricted this service to the servers where it works correctly, and since servers are replaced every day, one of its two instances landed on an affected server on October 19 and stopped working. The service kept running on a single instance for a week without any alert. On October 26, an unrelated infrastructure change automatically updated this service to a newer version[.](https://gitlab.com/fluidattacks/universe/-/merge_requests/119719) The restart moved the last healthy instance onto an affected server, leaving no instances available, so every AI service that depends on internal name resolution stopped responding. The new version itself was not the cause; both versions behave the same way on the affected servers. #### Solution The service was restored by restricting the internal name resolution service to servers without the new network layer, after which both instances started correctly. The permanent fix keeps this service on a dedicated group of base servers, the same placement already used by other core components, and raises that group to a minimum of two servers[.](https://gitlab.com/fluidattacks/universe/-/merge_requests/120043) A complementary change fixes the versions of the base components of our infrastructure, so updates are deliberate and reviewed instead of a side effect of unrelated changes[.](https://gitlab.com/fluidattacks/universe/-/merge_requests/120037) The team will also add an alert on the availability of this service. #### Conclusion This incident showed that the change to the network configuration of our servers was validated for the services it targeted but not for the base components of our infrastructure that could run on those servers, so the defect stayed hidden until the daily server rotation exposed it. Without an alert on the availability of name resolution and with component versions not fixed, a routine infrastructure update turned a silent degradation into an outage. Placing base components on dedicated servers, fixing their versions and monitoring their availability would have prevented any user from being affected. **INFRASTRUCTURE\_ERROR < MISSING\_ALERT < INCOMPLETE\_PERSPECTIVE** - **AGENT has degraded** (IDENTIFIED, 2026-09-12T23:11:10.000Z): An issue was found in AGENT.
Click for details: https://availability.fluidattacks.tech - **AGENT has degraded** (IDENTIFIED, 2026-09-12T05:18:32.000Z): An issue was found in AGENT.
Click for details: https://availability.fluidattacks.tech - **API has degraded** (IDENTIFIED, 2026-09-11T23:52:26.000Z): An issue was found in API.
Click for details: https://availability.fluidattacks.tech - **AGENT has degraded** (IDENTIFIED, 2026-09-11T23:47:08.000Z): An issue was found in AGENT.
Click for details: https://availability.fluidattacks.tech ## Fluid Attacks outage FAQ ### Is Fluid Attacks down right now? No, it's up. 0 reports in the last hour. ### Is Fluid Attacks down for everyone or just me? It looks like it's just you. Reports for Fluid Attacks are at their usual level, so try reloading, checking your connection, or signing out and back in. ### What problems are people reporting with Fluid Attacks? Nobody has said what's broken with Fluid Attacks in the last hour. If something isn't working for you, pick it above so others can see. ### When was the last Fluid Attacks outage? Reports for Fluid Attacks haven't spiked in the last 30 days. ### Does Fluid Attacks have a status page? Yes. Fluid Attacks posts updates on its official status page, which currently says operational. [Go to status page](https://status.fluidattacks.com/) ### What can I do if Fluid Attacks isn't working? Check this page and Fluid Attacks's status page for updates, and wait a few minutes before trying again. Skip reinstalling: if it's an outage, the fix is on their side. ### How do I report a Fluid Attacks problem? Hit “I have an issue too” at the top of this page and pick what's broken. Your report shows on the live chart within a minute, and you can leave a comment to tell others what you're seeing. ### How does Instatus Now know? We combine reports from people on this page with Fluid Attacks's official status page, which we check every minute.