Free Screenly Player with every Business or Enterprise yearly plan. How it works →

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: true
import { 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.