Connect WordPress Errors to Sentry with wp-sentry

If you run a WordPress site and want PHP failures or browser-side JavaScript errors to appear in Sentry, the unofficial plugin stayallive/wp-sentry sends those errors to Sentry. Sentry is a service for collecting and reviewing errors from software. The plugin is now named Sentry for WordPress, while its repository and Composer package still use stayallive/wp-sentry.

Installing and activating the plugin does not start reporting by itself. You must configure a DSN, a Sentry project address and key that tell the plugin where to send events. PHP and browser reporting use separate settings, so you can enable either one or both. The plugin documentation also covers testing events, adding deployment context, and loading the integration early enough to catch some errors from other plugins.

Choose which errors to send

PHP runs on the web server, so PHP reporting captures errors from WordPress code executing there. Browser reporting captures JavaScript errors while a visitor’s browser runs site code. Configure the PHP DSN with WP_SENTRY_PHP_DSN and the browser DSN with WP_SENTRY_BROWSER_DSN. Setting one does not configure the other.

The plugin supports performance tracing and profiling, along with session replay. It also offers feedback and log reporting. Start with error reporting, then enable other features only when you have a clear use for the data they collect. For example, PHP profiling requires the Excimer extension and tracing; PHP tracing also enables SAVEQUERIES, which stores executed database queries in memory and can increase memory use.

Configure the plugin and verify delivery

Install Sentry for WordPress through the WordPress plugin interface, or use one of the installation methods documented in the project repository. Add the constants you need to wp-config.php, above the “That’s all, stop editing!” line. Constants placed after that line will not configure the plugin.

define( 'WP_SENTRY_PHP_DSN', 'PHP_DSN_FROM_SENTRY' );
define( 'WP_SENTRY_BROWSER_DSN', 'BROWSER_DSN_FROM_SENTRY' );

define( 'WP_SENTRY_VERSION', 'your-deployment-or-build-id' );
define( 'WP_SENTRY_ENV', 'production' );

Replace the DSN placeholders with the values from your Sentry project. Omit a tracker’s constant if you do not want to enable that tracker. The older constants WP_SENTRY_DSN and WP_SENTRY_PUBLIC_DSN remain supported; the newer names distinguish the PHP settings from the browser settings.

After activating the plugin, use its diagnostic page to test the DSN and send test events. Then confirm that the events arrive in the intended Sentry project. A successful activation alone does not prove that the plugin can reach Sentry.

Set WP_SENTRY_VERSION to a deployment or build identifier if the active theme’s version does not identify your code release. Otherwise, the plugin uses the active theme version when available, or labels the version unspecified. Set WP_SENTRY_ENV to a value such as production or staging so you can distinguish events from different environments. These labels help identify where an error occurred; the plugin documentation does not say that they create Sentry releases, upload source maps, or register deployments.

Decide whether the plugin needs to load earlier

A standard WordPress plugin can miss errors from plugins that load before it. The integration’s documentation describes a must-use plugin wrapper, a small loader placed in wp-content/mu-plugins, as one way to load Sentry for WordPress before ordinary plugins. The repository advises keeping the original plugin installed so WordPress can still update it.

The project also documents loading the integration from wp-config.php to start it earlier; use the correct file path and define the Sentry constants before the require_once line that loads the plugin. Test either early-loading method in staging, and keep a recovery path in case a path or bootstrap change prevents WordPress from loading normally. Early loading improves the chance of catching errors from other plugins; it does not guarantee capture of every PHP failure.

Review privacy and event content

The WP_SENTRY_SEND_DEFAULT_PII setting controls whether the integration adds certain personal information to events. When enabled, the plugin adds the current logged-in user and IP address. Decide whether your site needs that context before enabling it, and check your own privacy and data-retention requirements.

Treat browser-side context as public. The plugin warns that custom values shared with the JavaScript tracker can be exposed in the browser, so do not put credentials, private user metadata, or other sensitive values there. For PHP events, the wp_sentry_before_send filter lets code modify an event or discard it by returning null. Sentry also provides project-level data-scrubbing settings; its project API documentation describes built-in scrubbing and custom sensitive fields. Filtering events before sending them to Sentry and scrubbing data in Sentry are separate controls, so review both.

Check compatibility before upgrading

The WordPress.org listing reports WordPress 4.4 or later, while the repository readme says WordPress 4.5 or later. Because those minimums conflict, check the requirements listed for the release you plan to install, especially on an older WordPress site. The plugin listing and repository readme give release and compatibility details.

The plugin includes WordPress-specific integrations for errors in background tasks handled by Action Scheduler and in Redis Object Cache operations. Its changelog also records major PHP and browser SDK upgrades, including releases with breaking changes. If you use custom Sentry integrations, test plugin upgrades in staging and review the changelog before deploying them.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com