June 19, 2026
Edge Apps can send their errors to your own Sentry project
An Edge App that fails on a screen in another building usually fails quietly. Nobody is standing in
front of it with the developer tools open. With setupSentry() and reportError(), those errors
land in your own Sentry project instead, with enough context to tell which screen sent them.
Add a sentry_dsn setting to screenly.yml, set it to your project’s DSN in Screenly, and call
setupSentry() once when the app starts:
settings:
sentry_dsn:
type: secret
title: Sentry Client Key
optional: true
is_global: trueimport { setupSentry, reportError } from '@screenly/edge-apps'
setupSentry('menu-board')
try {
await refreshPrices()
} catch (error) {
reportError(error, { source: 'price-feed' })
}Every event is tagged with edge_app (the name you pass) and the screen’s hostname, which is
also set as the Sentry user, so one screen’s errors group together. The optional second argument
to setupSentry() attaches contexts of your own, such as the URL a report was embedded from. The
second argument to reportError() goes in as extra data on that event.
Before an event leaves the screen, the value of any setting whose key contains token, secret,
password, or credential is replaced with [REDACTED] wherever it appears in the event. If an
event can’t be checked that way, it isn’t sent. The same filter is exported as
scrubSensitiveData() if you initialize Sentry yourself and want it as your beforeSend.
Leave sentry_dsn empty and setupSentry() does nothing, so the same build runs with or without
error reporting. It reports errors only, with no performance tracing.