---
title: "Sentry"
description: "Connect Sentry so each recording shows the errors your backend reported for its failed requests, matched by trace id."
canonical: https://faylee.app/docs/integrations/sentry
---

# Sentry

A failed request in a recording tells you what the browser saw: a 500, a timeout, an error message in the body. Your backend usually knows more. With Sentry connected, Faylee asks Sentry for the errors recorded in the same trace as each failed request and shows them next to the recording, so you see both sides of the failure in one place.

## Connecting Sentry

A workspace admin connects Sentry under **Settings**, **Integrations**, in the **Backend** group.

With one-click connect, click **Connect** and install Faylee in your Sentry organization.

With keys, fill in:

| Field | Value |
|---|---|
| Organization slug | Your Sentry organization's slug, such as `acme` |
| Auth token | An internal integration or personal token with `event:read` and `org:read` |
| Sentry URL | Only for self-hosted Sentry, such as `https://sentry.example.com`. Leave it empty for sentry.io. |

Faylee checks the token with Sentry before it saves the connection.

## How errors are found

Faylee finds backend errors through trace ids, the ids that tie a request in the browser to the work your servers did for it.

1. After a recording is uploaded, Faylee looks at its failed requests: requests that failed outright, and requests answered with a status of 400 or above.
2. It reads the trace id from each one's `traceparent` or `sentry-trace` header, in the request or the response.
3. It asks Sentry for the errors recorded in each trace, newest first.

Faylee looks up at most 10 traces per recording and keeps at most 10 errors per trace.

For this to find anything, your requests have to carry a trace id that Sentry knows. That means your frontend sends a `traceparent` or `sentry-trace` header with its API requests, or your backend returns one, and your backend reports its errors to Sentry with that trace.

:::tip
Open a failed request in the Network tab and look at **Backend trace** in its details, which lists each trace header and its id. If neither `traceparent` nor `sentry-trace` is listed, Faylee has nothing to look up in Sentry for that request.
:::

## The Backend tab

When Sentry had errors for a recording, the viewer's devtools show a **Backend** tab with the number of errors on it. The tab only appears when there is something to show.

Each row shows:

- The error's level and title. The title links to the event in Sentry.
- The culprit, where Sentry says the error came from.
- The request it belongs to, such as `POST https://api.example.com/orders`.
- The time of that request in the recording. Click it to seek the player there.
- A link to the whole trace in Sentry, with the trace id and the Sentry project.

### Looking up again

Sentry sometimes receives an error a little after the request failed, so the first look-up can come back empty. **Look up again** at the top of the Backend tab asks Sentry again.

When the Backend tab isn't shown, the Info tab has a **Backend errors** row. It says "Not looked up yet" or "None matched the failed requests", with a **Look up** or **Look up again** button.

## What the assistant sees

The errors Faylee found are part of the capture the assistant reads. Each one is a line at the time of its request, with the level, the request, the trace id, the error's title and its culprit. The assistant can then connect a failed request to the exception your server threw, and point you at the backend code as well as the frontend.

`faylee evidence` in the CLI prints the same lines. See [The faylee CLI](https://faylee.app/docs/agents/cli.md).

## Related

- [Integrations overview](https://faylee.app/docs/integrations/overview.md)
- [Console, network and more](https://faylee.app/docs/viewer/devtools.md)
- [The assistant](https://faylee.app/docs/viewer/assistant.md)