Skip to content

Investigations

Alerts that land in a Slack channel Fixter watches are investigated automatically. An AI agent reads the alert, queries your telemetry, and replies in the same thread with root cause, who is affected, and what to do. You can also mention the bot in any channel to start an investigation yourself.

Turn on auto-investigate for a Slack channel and every alert posted there is investigated. Nobody has to ask for it, and the answer arrives in the alert’s own thread rather than somewhere you have to go and look.

It is one toggle on the channel, in Settings > Integrations; an agent can do the same over the investigation MCP tools. The bot has to be invited to the channel by a person first, which is a Slack rule rather than a Fixter one. See Slack.

Not every problem arrives as an alert. Mention the bot wherever the conversation is already happening and ask:

#support
Ana09:14

A customer says their CSV exports have been failing since this morning. Account 4471. Anything our end?

you09:16

@Fixter can you check this? Exports for account 4471, anything since about 08:00.

FixterAPP09:18

Root cause: the export itself succeeds and then fails in the PDF render step. render-service has returned 502 on every /render call since 07:52, four minutes after its 07:48 deploy. 502s in render-service

Affected accounts: 23 unique. Sample: 4471, 1180, 9032, 5514

Action required: roll back render-service to the 07:12 build. Queued exports retry on their own once it is healthy.

🔍 Pick up in Claude Code: clever-nimble-otter-31

Every claim about what broke carries a link back to the query it came from, so a finding stated without one is a finding the agent could not evidence. The affected-entities callout gives real ids rather than a range, so you can paste them straight into a query of your own.

The thread stays live. Replying to it resumes the same session with everything already examined still in context, so you can ask why it concluded that, or ask it to check a theory of yours. Fixter can also post issue digests on a schedule: recurring issues grouped by the fix they share.

Every reply ends with a pick-up slug. Give it to your AI coding agent, once that agent is connected over MCP:

start_investigation("clever-nimble-otter-31")

Session takeover. That call claims the investigation, recording you as the person working it, and returns the original run’s full transcript: every query the investigating agent made and everything it got back. Your coding agent carries on from that point with your code in front of it, instead of re-deriving what has already been worked out. Use get_investigation_brief instead when you only want to read one; it returns the same transcript without claiming it.

The other route is to let an AI agent write the change. With the Fixter GitHub App installed, an investigation can end in a pull request on the affected repository rather than a description of what to change. Setup is self-serve and takes one message to the bot, covered in GitHub.

What a reviewer needs to know before merging one:

  • In beta. Every pull request is reviewed by someone at Fixter before it reaches you.
  • Not built or tested. Fixter does not run your build or tests against the change. Review it as you would a colleague’s.
  • Never merged for you. Fixter opens the pull request; merging stays your call.
  • Ephemeral code access. The repository is cloned into a temporary isolated environment that lasts only as long as the investigation or fix. Your code is not stored beyond that, and caches are invalidated when the run ends.

None of this is required. Without GitHub you still get root cause and blast radius, and you write the fix yourself or pick the investigation up in your own AI coding agent.

Investigations do not need your telemetry to be in Fixter. Point them at the monitoring you already run and the agent queries that instead, over the same Slack flow with the same replies. Supported sources:

  • Datadog. Store API and application keys. They are write-only and encrypted, so they cannot be read back out.
  • AWS CloudWatch. Same credential handling, plus a read-only Logs IAM policy on your side.

Migrating your telemetry to Fixter later changes where the agent reads from, and nothing else.

  • Nothing happens when an alert fires. Either auto-investigate is off for that channel, or the bot was never invited. Turn the toggle on in Settings > Integrations, and run /invite @Fixter in the channel.
  • One alert was investigated and another was not. Only alerts posted by your alerting tool start an investigation on their own. An alert a colleague pasted in by hand does not, though you can mention the bot on it. A per-channel exclusion can also be matching.
  • Fix requests fail. The GitHub App has to be installed and the repository granted to it. See GitHub.

Still stuck? Email info@fixter.dev and one of our founders will help you fix your problem asap.

  • Alerts: what fires an investigation in the first place
  • Slack and GitHub: the two connections this depends on
  • MCP tools: the investigation tools an agent can call