Observability When You Can’t Just SSH In

This is part of a series on the modern web stack, written from a WordPress developer’s seat for people who’ve built on the web for years and still hit stack terms they can’t define. The goal is literacy, enough that you can read any stack list and know what each piece does.

Each post has a 10-15 minute audio companion, generated with NotebookLM, for the gym or the commute.

For most of my WordPress career, debugging production meant ssh [email protected], a cd into the public folder, tail -f error_log, a page refresh, and watching the errors stream by. For more context I’d enable WP_DEBUG_LOG, reproduce the bug, and scroll through wp-content/debug.log for the stack trace. Crude and manual, but when something broke I knew where to look.

The first time I debugged a Next.js app on Vercel, I stared at the dashboard like I’d never used a computer. No SSH, no error log file. A “Logs” tab streamed cryptic JSON, and a “Functions” tab showed execution metrics I couldn’t interpret. Something was failing for 8% of users and I had no idea where to start.

This post covers what replaces tail -f error_log when there’s no server to log into, which services have grown up around the problem, and how a WordPress veteran should think about production debugging in 2026.

The Three Pillars

Observability means understanding what’s happening inside your application from the outside. It’s usually split into three pillars.

Logs

Logs are text records of what happened, the same job as WordPress’s error_log. Modern apps produce far more of them, and storage is distributed, so you search, filter and aggregate across many sources instead of opening one file in a terminal.

Metrics

Metrics are numbers over time: requests per second, p95 latency, error rate, database query time, memory usage. WordPress has nothing built in for this, so you bolt on New Relic or similar. Modern platforms expose metrics natively.

Traces

A trace follows one request through the system. A user clicks a button, the request hits the edge, gets routed to a Node function, which queries the database, calls a third-party API and returns a response. The trace shows which step took how long. The Query Monitor and debug bar plugins gave WordPress a small taste of this, and modern tooling does it across distributed systems.

Most tooling adds error tracking as a fourth pillar: which errors are happening, how often, to which users, in which contexts, on which code paths.

The big shift from WordPress is that no single error log file exists anymore. Logs come from dozens of sources: edge functions, server functions, the database, third-party services and the client browser (serverless and edge setups multiply them further). You need a layer that collects all of them, makes them searchable and alerts you when something’s wrong.

The WordPress Analogue

Sentry is what tail -f error_log always wanted to be. Logflare and Datadog do for logs what grep across a thousand files would do. Vercel Analytics and Plausible are the traffic metrics WordPress’s “Stats” widget was reaching for.

WordPress mostly assumed you wouldn’t need any of this until you grew big. Modern apps need it from day one, because production runs on someone else’s infrastructure and you can’t SSH in to look around. The instrumentation goes in at the start instead of after the first fire.

Today’s Observability Stack

The main observability services in 2026:

My default 2026 stack is Sentry for errors, Axiom or Better Stack for logs, Vercel Analytics for first-party metrics and Plausible for visitor analytics. That combination runs roughly $40-100/month for a small SaaS, and it replaces what WordPress users built ad hoc from error_log, Cloudflare analytics and a paid plugin.

Sentry also has a PHP SDK that works inside WordPress. Adding it to a WP site you operate takes about an hour and pays off the first time a customer reports a white screen.

What This Changes for WordPress People

You always know what broke

Before observability tooling, the default state of a production app was partial ignorance. With Sentry installed, every error arrives with a stack trace, the request that caused it, the affected user and a breadcrumb trail of what happened just before. Bugs go from “we’ll look into it” to fixed within the hour.

Performance becomes measurable

Vercel Analytics and similar tools record real user metrics: page load, time to interactive, cumulative layout shift. Instead of guessing whether the site is fast, you watch the p95 latency curve move after each deploy. For client work, that’s a deliverable you can show.

Privacy-friendly analytics are viable

Plausible, Fathom and Umami cost less than Google Analytics, run faster, skip cookies and report the numbers that matter: which pages, which referrers, what conversion. Several WordPress sites have moved to them in the last two years, and the modern stack defaults to them.

Don’t Ship Without Source Maps

A few traps are worth knowing before your first real incident.

Source maps

Without source maps, Sentry shows stack traces in minified JavaScript you can’t read. Configure source map uploads as part of your CI pipeline (the GitHub Actions post covers the setup). Most modern frameworks, Next.js and SvelteKit included, wire this in automatically. Check that it works the first time you ship a real error.

Log volume

Every log line costs storage. A console.log("hi") in a hot path produces millions of useless entries a day. Structure logs as JSON instead of free text, make the levels mean something, and turn debug logs off in production unless you’re actively investigating.

Trace sampling

A trace per request scales linearly with traffic. Most tracing tools sample, for example 1 in 10 traces, or every error plus 10% of successes. Set the sampling rate deliberately or the bill grows with the site.

Privacy

Detailed user analytics, session replay (PostHog’s headline feature) and full error context all collect data that may fall under GDPR or similar rules. Audit what your tools capture, and add data scrubbing where needed, such as Sentry’s Data Scrubbers.

Free tier limits

A bug that fires 100k times in an hour will exhaust your Sentry free tier event quota, right when you most need the data. Set alerts on quota usage so you find out before events stop arriving.

Sharpen Your Observability Sense

A few resources if you want to build the intuition.

YouTube

• “The Three Pillars of Observability”: search for talks by Honeycomb’s Charity Majors, about 30 minutes each. They frame the concepts at the right level.
• “Sentry Tutorial” on the Sentry YouTube channel, about 30 minutes. Setup, source maps and the basics of triage.

Official docs

• Sentry docs: the platform-specific install guides (Next.js, WordPress and others) are excellent, and the performance monitoring pages cover tracing.
• Vercel Analytics docs: quick to read and immediately useful for Vercel-hosted apps.
• PostHog docs: PostHog bundles analytics, session replay, feature flags, experiments and A/B testing, so a skim shows you what’s in scope.

If you’re still working out where this fits among the other pieces, how the pieces wire up traces one request through the whole stack. The next post moves to a different topic: Tailwind, shadcn/ui and the design-system meta that replaced the WordPress theme stylesheet world.

Related

A Collection of Thoughts and Life Lessons

Mintos Review 2026 – My Results in 9 Years and Over €150,000 Invested

How to Back Up a Self-Hosted App So an AI Agent Can’t Delete the Backups

eToro Review 2026 – Is It the Best Social Trading Platform?

My Best Travel Tips – Accommodation, Flight Prices Etc

How to Secure a VPS Server: A Plain-English Guide