# Investigations
> Alerts landing in a Slack channel Fixter watches are investigated automatically: an AI agent queries your telemetry and replies in the thread with root cause, who is affected, and what to do.
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.
## Every alert in a channel
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](https://app.fixter.dev/settings/integrations); an agent can do
the same over the [investigation MCP tools](/reference/mcp-tools/#investigations). 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](/setup/slack/).
## On request, in any channel
Not every problem arrives as an alert. Mention the bot wherever the conversation is
already happening and ask:
A customer says their CSV exports have been failing since this morning. Account 4471.
Anything our end?
@Fixter can you check this? Exports for account 4471,
anything since about 08:00.
## What comes back
**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](https://app.fixter.dev/logs)
**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.
## Continuing with your AI coding agent
Every reply ends with a pick-up slug. Give it to your AI coding agent, once that agent
is [connected over MCP](/setup/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.
## Letting AI write the fix
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](/setup/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 on their own
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.
## If investigations do not run
- **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](https://app.fixter.dev/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](/setup/github/).
Still stuck? Email [info@fixter.dev](mailto:info@fixter.dev) and one of our founders will help you fix your problem asap.
## Related
- [Alerts](/using-fixter/alerting/): what fires an investigation in the first place
- [Slack](/setup/slack/) and [GitHub](/setup/github/): the two connections this depends on
- [MCP tools](/reference/mcp-tools/#investigations): the investigation tools an agent can call