Monitoring

The site reports application errors and frontend performance to GlitchTip, a Sentry-compatible monitoring tool on private infrastructure. This is separate from two other things: uptime monitoring (the /healthz endpoint, see Operations) and analytics (visitor behavior, see Event Tracking). Monitoring is about errors and performance: what's breaking and what's slow.

Error tracking

PHP and JavaScript errors are captured by the wp-sentry-integration plugin and sent to the WHA project in GlitchTip at errors.joeyyax.dev.

• PHP errors — uncaught exceptions, fatals and warnings from WordPress, the theme and plugins.
• JavaScript errors — front end, wp-admin and the login page.

Errors are grouped into issues. An issue stays unresolved until someone resolves it, and if a resolved issue happens again it reopens as a regression.

What's filtered out

WordPress and older plugins generate a constant stream of low-value PHP deprecation and notice messages: PHP 8.x deprecations, _load_textdomain_just_in_time notices and similar. Left unfiltered these flood the project and bury real problems; the WHA project took on thousands of them in minutes before filtering.

The SENTRY_ERROR_TYPES setting strips that noise. It excludes deprecation and notice level messages while keeping warnings, uncaught exceptions and fatals. Those three always report regardless of the setting.

Performance monitoring

GlitchTip also captures performance through browser tracing: real-user Core Web Vitals (Largest Contentful Paint, layout shift, interaction latency, time to first byte) and page-load timing, sampled at 10% of page loads. This shows how the site actually performs for visitors, not a lab score.

• Sampling is controlled by SENTRY_BROWSER_TRACES_SAMPLE_RATE (browser) and SENTRY_TRACES_SAMPLE_RATE (PHP). Each sampled transaction is stored, so the rate is kept low on a public site.
• Events are retained for 90 days.

What GlitchTip doesn't do

GlitchTip is Sentry-compatible but doesn't support two Sentry-only features. Don't try to enable them; the data has nowhere to land:

• Profiling — needs the excimer PHP extension, but GlitchTip can't ingest profiles. Leave it off.
• Session replay — GlitchTip doesn't process replays. Don't set the WP_SENTRY_BROWSER_REPLAYS_* rates.

Configuration

Monitoring is environment-driven, like the rest of the site (see Hosting). It only activates when SENTRY_DSN is set, so local development stays silent unless you configure it. Settings live in wp-config.custom.php and read from these variables:

The DSN is a credential available from the developer (see Contacts), not stored in the repo. Changing any of these is a config-var change on the host and takes effect on the next restart or redeploy, with no code change.

Viewing errors

Sign in at errors.joeyyax.dev and open the WHA project. Issues are listed newest-first and can be filtered by status; performance data lives under the project's Performance tab. Issue alerts are emailed to the project's configured address. Alerts route to the developer, who triages and responds; see Contacts for response times.

Operator analytics (Plausible)

GlitchTip is the operator's lens for errors and performance; Plausible is the operator's lens for traffic. It's a cookieless analytics instance on private infrastructure that the developer uses to verify on-site events actually fire and to sanity-check traffic, independent of the marketing stack.

This is deliberately separate from the marketing analytics (FreshPaint → GA4) that the content team uses for conversions. Plausible receives the same named events as an event-tracking adapter, but serves observability rather than marketing measurement. Sentry-compatible GlitchTip plus cookieless Plausible are the two halves of the developer-facing observability stack.

See Operations for uptime and health checks, and Event Tracking for visitor analytics.