> ## Documentation Index
> Fetch the complete documentation index at: https://docs.incident.io/llms.txt
> Use this file to discover all available pages before exploring further.

# What investigations can see

> The context an investigation reads from inside your incident: the conversation, the call, shared files, and the incident's own details.

An investigation reads your incident the way a responder joining late would: it catches up on the conversation, the call, the files people have shared, and the incident's own details, then reasons over all of it at once. This page covers what's visible to an investigation from inside an incident, separate from the [external sources you connect](/investigations/connect/overview), which add even more.

## The channel conversation

Every message in the incident channel is part of what an investigation reads, both what people say and what your bots post. It follows threads, not just top-level messages, so a detail buried in a reply isn't lost.

Human discussion gives it the context telemetry can't: a suspected cause, a migration someone mentions in passing, a decision to roll back. Automated messages (deploy bots, CI, alert notifications) are read too, and the ones that describe a change are also turned into [change events](/investigations/connect/change-events) so they can be lined up against the incident timeline.

<Note>
  This is the incident's **own** channel, which an investigation always reads. Connecting *other* Slack channels (your
  `#deploys` channel, an infrastructure channel) is a separate source. See [Slack
  channels](/investigations/connect/slack).
</Note>

<Tip>
  Anything you tell the investigation by tagging `@incident` becomes context too. If you know something it doesn't, say
  so. See [Ask and steer with @incident](/investigations/incident-channel-experience#ask-and-steer-with-incident).
</Tip>

## Call transcripts

If you use [Scribe](/ai/scribe), our AI note-taker that joins your incident calls, the call transcript is available to the investigation as evidence, alongside the channel conversation. That means an investigation can pick up things only said out loud on the call: a hypothesis someone floated, a config change being made live, the moment a fix went out, and who said what.

So when someone asks "do you use the Scribe transcript?", the answer is yes. While Scribe is transcribing an incident call, what's discussed there feeds into the investigation just like the messages in the channel do.

<Info>
  Scribe stores only the call transcript, never the audio or video, and is available on Pro and Enterprise plans once a
  call provider is set up. See [Scribe](/ai/scribe) for how it works and how to enable it.
</Info>

## Attachments

People drop a lot into incident channels: a forwarded alert email, a pasted stack trace, a chunk of config. Investigations read these too, pulling in the full content when it's relevant rather than just the filename.

<ResponseField name="Forwarded emails">
  The subject, sender, recipients, and full body of an email shared into the channel, so a forwarded alert or vendor
  notification is read in full, not just noted.
</ResponseField>

<ResponseField name="Text snippets and files">
  Pasted snippets and uploaded text files: logs, stack traces, configs, and structured formats like JSON, YAML, and XML.
  The full content is read on demand, up to around 500,000 characters; very large files (over 5 MB) keep a preview
  instead.
</ResponseField>

<ResponseField name="Code blocks">
  Code and snippets pasted inline in a message are read as part of that message.
</ResponseField>

Deleted files are skipped: once a file is removed there's nothing left to read.

<Tip>
  Attachment content is tied to the incident and the channels a file was shared into. Content shared in a private
  incident is only ever read within that incident, never pulled into another conversation.
</Tip>

## The incident's own details

Beyond the conversation, an investigation reads the structured incident record, which tells it what kind of incident this is and how it has evolved:

| Source                     | What it adds                                                                 |
| -------------------------- | ---------------------------------------------------------------------------- |
| **Status and severity**    | How serious the incident is and where it is in its lifecycle.                |
| **Custom fields**          | Your own metadata: affected service, region, team, and the like.             |
| **Roles and participants** | Who's involved and in what capacity.                                         |
| **Updates and timeline**   | What's been communicated and the sequence of events so far.                  |
| **Alerts**                 | The alerts that triggered the incident, including any error and stack trace. |
| **Actions and follow-ups** | What's been done and what's still outstanding.                               |
| **Postmortem**             | The postmortem document, if one exists.                                      |

## Everything you connect

What's visible inside the incident is only part of the picture. Investigations also draw on the [sources you connect](/investigations/connect/overview), like past incidents, telemetry, code repositories, documentation, and other Slack channels, plus an automatic check of whether your [third-party dependencies](/investigations/third-party-dependencies) were having an outage. The more you connect, the more grounded each investigation becomes.

## FAQs

<AccordionGroup>
  <Accordion title="Do investigations use the Scribe call transcript?">
    Yes. While Scribe is transcribing an incident call, that transcript is available to the investigation as evidence,
    so it can use what was said on the call alongside the messages in the channel. See [Scribe](/ai/scribe).
  </Accordion>

  <Accordion title="Which channels can an investigation read?">
    The incident's own channel, always, plus any other Slack channels you explicitly [connect as a
    source](/investigations/connect/slack). It doesn't read direct messages or channels you haven't connected.
  </Accordion>

  <Accordion title="What kinds of attachment can it read?">
    Forwarded emails, pasted text snippets, and uploaded text files such as logs, stack traces, configs, and JSON, YAML,
    or XML. It reads text-based content; the full body is loaded when it's relevant, capped at around 500,000
    characters, with very large files (over 5 MB) keeping a preview.
  </Accordion>

  <Accordion title="How is what's visible kept private?">
    Attachment content carries the incident and channels it was shared into, and content from a private incident is only
    served back within that incident. For how incident.io handles your data during AI processing, see our [Trust
    Center](https://trust.incident.io/).
  </Accordion>
</AccordionGroup>

## Related

<CardGroup cols={2}>
  <Card title="How investigations work" icon="magnifying-glass" href="/investigations/how-investigations-work">
    How this context becomes findings backed by evidence.
  </Card>

  <Card title="Incident channel experience" icon="slack" href="/investigations/incident-channel-experience">
    What an investigation looks like in your channel, and how to talk to it.
  </Card>

  <Card title="Connect your data" icon="server" href="/investigations/connect/overview">
    The external sources investigations draw on, and how to set each one up.
  </Card>

  <Card title="Scribe" icon="microphone" href="/ai/scribe">
    AI transcription and summaries for your incident calls.
  </Card>
</CardGroup>
