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

# Connect Sentry to Cogno

> Connect Sentry so new and escalating production errors reach Cogno, which decides whether the board already covers them.

<img src="https://mintcdn.com/genaxis/J2ujCHptx0vB7U8v/images/integrations/sentry-mono.svg?fit=max&auto=format&n=J2ujCHptx0vB7U8v&q=85&s=585c73ebfacd214856343047a3563b06" alt="Sentry" width="56" height="56" noZoom data-path="images/integrations/sentry-mono.svg" />

## At a glance

|                    |                                                                                        |
| ------------------ | -------------------------------------------------------------------------------------- |
| **Direction**      | Receive — Cogno reads issues from the Sentry projects you name and never changes them. |
| **Connect with**   | Sentry OAuth — one click.                                                              |
| **Who can set up** | A member with the **Manage integrations** permission.                                  |
| **You'll need**    | A Sentry account with access to the organization you want read.                        |

Connect Sentry to stop production errors from living only in an alerts channel. Cogno watches the Sentry projects a project is bounded to, and when something new or escalating appears it checks whether the board already covers it before raising anything.

## Before you start

* Decide which Cogno project should receive the issues. Sentry projects are named per Cogno project, under **Filter**.
* Know which Sentry organizations you want read. An authorization covers the ones your Sentry account can see; an organization it cannot see needs a connection from somebody who can.

## Connect Sentry in Cogno

<Steps>
  <Step title="Open the Sentry integration">
    Go to **Settings** → **Integrations** and select **Sentry**.
  </Step>

  <Step title="Authorize Cogno">
    Select **Connect Sentry** and approve in Sentry. The browser returns to Cogno and the connection is completed there. Sentry does not ask which organization — that choice is made in Cogno, next.
  </Step>
</Steps>

## Choose what the connection reads

A Sentry authorization follows the person who granted it, not one organization — so a connection usually arrives able to see more than you meant to connect. Two choices narrow it, both on the connection:

<Steps>
  <Step title="Pick the organizations">
    Under **Organizations**, tick the ones Cogno should read. Everything else the authorization can see stays out of reach. A connection that sees exactly one organization has it ticked already — there was nothing to choose.
  </Step>

  <Step title="Pick the projects">
    Under **Projects Cogno offers**, tick the projects a Cogno project may then pick from. Untick the rest and they stop appearing anywhere.
  </Step>
</Steps>

Neither choice starts reading anything. They decide what is *available*; a Cogno project still has to name it under **Filter**.

## When you need a second connection

Only when the organization is one your Sentry account cannot see. Then the person who can see it adds their own:

<Steps>
  <Step title="Add their account">
    Select **Add a Sentry account** and approve in Sentry, signed in as that person.
  </Step>
</Steps>

Each connection is disconnected on its own, and removing one leaves the others alone.

## Choose which projects a project reads

Connecting an organization does not by itself bring in any issues. What a Cogno project takes from Sentry is set on that project, the same way Slack channels and GitHub repositories are:

<Steps>
  <Step title="Open the project">
    Select the project in the sidebar and open its **Configuration** panel.
  </Step>

  <Step title="Add Sentry projects to Filter">
    In **Filter**, select **+** next to **Sentry** and pick the projects this project should read. Cogno only takes events from what is listed here.
  </Step>
</Steps>

Sentry projects are listed as `organization/project`, because a project slug is only unique inside its organization. A Sentry project can be named by more than one Cogno project. A project with nothing listed receives nothing.

## What Cogno does with an error

Cogno checks the projects you named every few minutes and reacts in two cases:

| Case           | When                                                                                     |
| -------------- | ---------------------------------------------------------------------------------------- |
| **New**        | The issue has not been seen before.                                                      |
| **Escalating** | Sentry marks the issue as escalating, or its volume has multiplied since the last check. |

An issue that simply keeps happening produces nothing further — it is reacted to once, not on every check.

Cogno does not file a task for every error it detects. It reads the issue — how many people it has reached, whether it started with a release, whether it has been raised before and left — searches the project for issues that arrived alongside it, and checks the board. A dozen errors appearing together is a deploy rather than a bug, and an error the board already covers needs nothing. When it does warrant attention, Cogno raises it or hands it to a local agent to triage against the code.

An agent working on the error can read Sentry directly: the exception and the file and function it was raised in, and — for one occurrence — the application stack frames, the source around the failing line, the request that triggered it, and the release it shipped in. It reads only the Sentry projects the Cogno project it is working on has in its **Filter**, and nothing it does changes anything in Sentry.

<Note>
  A project is read for the first time when you add it to a **Filter**, and that first read records what is already open without reacting to it. A workspace connecting Sentry is not woken for every error it has been living with.
</Note>

## Common states

| State                            | Meaning                                                                                             | Next action                                                                                   |
| -------------------------------- | --------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| **Connected**, nothing arriving  | The connection offers projects, but no Cogno project reads from them yet.                           | Add Sentry projects to a project's **Filter**.                                                |
| **No organization chosen**       | Nobody has said which of this authorization's organizations Cogno reads.                            | Tick them under **Organizations** on the connection.                                          |
| Nothing happens after connecting | Nothing new or escalating has occurred since the first check, or the board already covers what has. | Wait for the next error, or confirm the project's **Filter** lists the right Sentry projects. |

## Disconnect

Select **Disconnect Sentry** on the connection you want removed. Cogno removes it and revokes its access on the Sentry side, so it can no longer read that organization's issues. Other connections are unaffected.

## Reference URLs

* [Sentry documentation](https://docs.sentry.io/)
* [Sentry organization settings](https://sentry.io/settings/)

## Related docs

* [Projects](/docs/projects)
* [Tasks](/docs/tasks)
* [Troubleshooting](/docs/troubleshooting)
