Configured the SECRET_LIST in GitHub Action to use SENTRY_DSN. I also see it when running lk agent secrets
│ SENTRY_DSN │ 2026-02-04T23:46:01Z │ 2026-02-06T00:05:09Z │
I don’t see any errors, logs in the Sentry dashboard when for example TTS times out or have an incorrect API token.
Sentry integration is only supported for agents hosted on LiveKit cloud: Log collection | LiveKit Documentation, but you can still use Agent observability to view your logs, or we also have OpenTelemetry integration for self-hosted agents: Data hooks | LiveKit Documentation
@darryncampbell Sorry for confusion. It’s actually on LiveKit Cloud, not self hosted
No worries, I’ve never actually tested Sentry myself, but it sounds like you have the setup correct. Do you see logs with lk agent logs or with agent observability (if you have it enabled)?
Also, please let me know if you had difficulties logging in, obviously this portal is new so quite possibly there are issues.
I use Sentry in several LiveKit projects and it works like a charm
Are you using the Python agents SDK? If so, a common reason for this is that setting SENTRY_DSN as a secret doesn’t automatically initialize the Sentry SDK in your agent process. You still need to explicitly call sentry_sdk.init() in your agent code with the proper integrations (notably LoggingIntegration and enable_logs=True).
The docs cover the basics, but in practice I’ve found you also need to pay attention to the event_level setting, since many framework-level errors (like TTS timeouts) may be logged at WARNING rather than ERROR, and by default only ERROR+ gets forwarded to Sentry as events.
Could you share your agent’s Sentry initialization code and any relevant logs from lk agent logs? That would help narrow down whether it’s an init issue or a log level filtering issue
I had to enable Agent Observability and properly initialize it with sentry_sdk.init(). I had assumed from the docs that just setting SENTRY_DSN would be enough, but thanks to this, it’s working now.
I thought it should automatically work, but indeed I can reproduce the same behaviour described in this thread. Let me check internally, either the docs are wrong, or something is broken.