This is part of an ongoing series I am writing as I work my way through the modern web stack from a WordPress developer’s perspective. It is for people who, like me, have built on the web for years and still hit words in a modern stack they could not confidently define. The goal is broad literacy, not deep mastery: by the end you should be able to read any modern stack list and know what each piece does.
Each post comes with an audio companion (10-15 minutes, generated via NotebookLM) for gym or commute listening. Press play below if that suits you better than reading.
For most of my WordPress career, “debugging production” meant ssh -p 28104 [email protected], navigate to the public folder, tail -f error_log, refresh the page, watch the errors stream by. If I needed more context I would enable WP_DEBUG_LOG, reproduce the bug, scroll through wp-content/debug.log, find the stack trace. Crude, manual, but reliable. When something broke, I knew exactly where to look.
The first time I tried to debug a Next.js app on Vercel I stared at the dashboard like I had never used a computer. There was no SSH. There was no error log file. There was a “Logs” tab with a stream of cryptic JSON. There was a “Functions” tab with execution metrics I could not interpret. Something was failing for 8% of users and I had no idea where to start.
This module is the observability layer of the modern stack. What replaces tail -f error_log when there is no server to log into, what services have grown up around the problem, and how a WordPress veteran should think about production debugging in 2026.
Observability is the discipline of understanding what is happening inside your application from the outside. It is conventionally broken into three pillars.
Logs are the text records of what happened. Same as WordPress’s error_log, but the volume in modern apps is higher and the storage is distributed. Logs are searched, filtered, and aggregated across many sources rather than just opened in a terminal.
Metrics are numerical measurements over time. Requests per second, p95 latency, error rate, database query time, memory usage. WordPress has nothing built-in for this (you bolt on New Relic or similar). Modern platforms expose metrics natively.
Traces are records of one specific request as it flowed through the system. A user clicks a button → request hits the edge → routed to a Node function → function queries the database → calls a third-party API → returns the response. A trace shows you exactly which step took how long. WordPress’s debug bar gave you a hint of this; modern tooling does it for distributed systems.
Add error tracking as a fourth pillar (most tooling does), and you have the full picture: which errors are happening, how often, to which users, in which contexts, on which code paths.
The big shift from WordPress: you cannot watch one error log file. Logs come from dozens of sources (edge functions, server functions, the database, third-party services, the client browser). You need a layer that collects all of them, makes them searchable, and alerts you when something is wrong.
The WordPress Analogue
Mental model: Sentry is to error tracking what
tail -f error_logalways wanted to be. Logflare and Datadog are to log aggregation what grep-across-files would be if you had a thousand files. Vercel Analytics and Plausible are to traffic metrics what WordPress’s “Stats” widget tried to be.The conceptual shift: WordPress mostly assumed you would not need this until you grew big. Modern apps assume you need this from day one because production runs on someone else’s infrastructure and you cannot just SSH in to look around. The instrumentation gets built in at the start, not bolted on after a fire.
Today’s observability stack
The main observability services in 2026:
| Category | Service | Best for | Free tier |
|---|---|---|---|
| Error tracking | Sentry | Catching runtime errors with stack traces, source maps, breadcrumbs | Generous (5k events/month) |
| Error tracking | Rollbar / Bugsnag | Older alternatives, still solid | Smaller free tiers |
| Logs | Logflare (Supabase) | Tight Supabase integration | Generous if on Supabase |
| Logs | Datadog | Enterprise-grade, deep integrations | Trial only |
| Logs | Axiom | Modern log platform, cost-effective | Generous |
| Logs | Better Stack (Logtail) | Logs + uptime monitoring bundled | Generous |
| Metrics | Vercel Analytics | First-party metrics for Vercel apps | Bundled (limited) |
| Metrics | PostHog | Product analytics + session replay + experiments | Generous |
| Tracing | Sentry (performance) | Tracing tied to error context | Bundled with Sentry |
| Tracing | Honeycomb | Best-in-class for complex distributed systems | Small free tier |
| Uptime / synthetic | Better Stack / Cronitor / Checkly | “Is the site up? Is the checkout working?” | Generous |
| Privacy analytics | Plausible / Fathom / Umami | Cookie-free visit counting, GDPR-friendly | Paid (no free tier on most) |
For a default 2026 stack: Sentry for errors, Axiom or Better Stack for logs, Vercel Analytics for first-party metrics, Plausible for visitor analytics. This combo costs roughly $40-100/month for a small SaaS and replaces what WordPress users built ad-hoc from error_log, Cloudflare analytics, and a paid plugin.
For WordPress projects specifically, Sentry has a PHP SDK that works inside WordPress. Adding Sentry to a WP site you operate is genuinely useful and takes maybe an hour.
What This Changes for WordPress People
Three practical wins.
The first is “I have no idea what is broken” stops being acceptable. Before observability tooling, the default state of any production app was partial ignorance. With Sentry installed, every error is captured with a stack trace, the request that caused it, the user it affected, and a breadcrumb trail of what happened just before. Bugs go from “we will look into it” to “fixed within the hour.”
The second is performance gets measurable. Vercel Analytics and similar tools record real user metrics: page load, time-to-interactive, cumulative layout shift. You stop guessing about whether the site is fast and start seeing the p95 latency curve change after each deploy. For client work, this is a deliverable you can show.
The third is privacy-friendly analytics become viable. Plausible, Fathom, and Umami cost less than Google Analytics, run faster, do not need cookies, and give you the analytics that actually matter (which pages, what referrers, what conversion). Several WordPress sites have moved to these in the last two years; the modern stack defaults to them.
Don’t ship without source maps
A few traps.
Source maps are essential for production errors. Without source maps, Sentry shows you stack traces in minified JavaScript that is unreadable. Configure source map uploads as part of your CI pipeline. Most modern frameworks (Next.js, SvelteKit) wire this in automatically; verify it works the first time you ship a real error.
Logging too much is its own problem. Every log line costs storage. Logging console.log("hi") in a hot path produces millions of useless entries per day. Logs should be structured (JSON, not free text) and the levels should mean something. Debug logs go off in production unless you are actively investigating.
Tracing without sampling is expensive. A trace per request scales linearly with traffic. Most tracing tools sample (record 1 in 10 traces, or all errors and 10% of successes). Configure sampling deliberately, otherwise the bill grows with the site.
Privacy and observability tension is real. Detailed user analytics, session replay (PostHog’s killer feature), and full error context all collect data that may be in scope for GDPR or similar regulations. Audit what your observability tools actually capture; add data scrubbing (Sentry’s “Data Scrubbers” feature) where needed.
Free tiers cap at the worst moment. A bug that fires 100k times in an hour will exhaust your Sentry free tier event quota. Set up alerts on quota usage so you know before you stop receiving events.
Sharpen your observability sense
If you want to develop observability intuition, a few resources worth your time.
YouTube, gym or commute friendly:
- “The Three Pillars of Observability” (search for talks by Honeycomb’s Charity Majors, ~30 min each). Frames the concepts at the right level.
- “Sentry Tutorial” on the Sentry YouTube channel (~30 min). Setup, source maps, the basics of triaging.
Official docs worth bookmarking:
- Sentry docs. The platform-specific install guides (Next.js, WordPress, etc.) are excellent. Read the “Performance Monitoring” pages for tracing.
- Vercel Analytics docs. Quick to read, immediately useful for Vercel-hosted apps.
- PostHog docs. PostHog tries to be five tools in one (analytics, session replay, feature flags, experiments, A/B testing). Worth a skim to see what is in scope.
Next post in the series moves to a very different topic: Tailwind, shadcn/ui, and the new design-system meta that replaced the WordPress theme stylesheet world.
Related
Leave a Reply