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
Section titled “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
Section titled “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.
- 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.
- It reads the trace id from each one’s
traceparentorsentry-traceheader, in the request or the response. - 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.
The Backend tab
Section titled “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
Section titled “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
Section titled “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.