Monitoring and observability for production web applications

In short: Monitoring tells you that something is wrong; observability helps you find out why. A production web application needs structured logs, a few meaningful metrics, error tracking and, for distributed systems, traces. What matters most is that alerts fire only for real user-facing problems, so your team takes them seriously.

Monitoring vs. observability

Classic monitoring checks known conditions: is the server up, is CPU too high, is the disk full? You need that, but it is not enough for modern web applications. Most incidents are far less obvious than a full outage: a slow checkout for one payment method, or errors that only affect users of a particular browser.

Observability is the ability to understand such unknown problems from the data, without knowing in advance what to look for. That requires the application to expose enough context about itself.

The three signals: logs, metrics and traces

Logs

Logs tell you what happened. To make them searchable, structure them as JSON with fixed fields such as timestamp, level, request ID and user ID, rather than free text. A request ID passed through every service turns scattered lines into one connected story.

Metrics

Metrics are numbers over time: requests per second, response times, error rate, resource usage. Google's Site Reliability Engineering book names four "golden signals" as a good starting point: latency, traffic, errors and saturation. Look at response times as percentiles (p95, for example), because averages hide slow outliers.

Traces

A trace follows a single request through every component involved: frontend, API, database, external services. It shows you which step takes the time. Traces matter less for a monolith with one database than for several services, but even there they expose slow queries very clearly.

Tools that work

OpenTelemetry has become the vendor-neutral standard for collecting logs, metrics and traces. Instrument your application with it and you can switch backends later without touching the code.

For analysis there are two routes. Self-hosted: Prometheus for metrics, Grafana for dashboards, Loki for logs and Tempo for traces. That gives full control over the data but needs operational effort. As a service: providers such as Grafana Cloud, Datadog or Better Stack run it for you. Error tracking with Sentry (hosted or self-hosted) belongs in almost every project, because it groups exceptions with stack trace, release and affected user.

External uptime monitoring that checks key pages and endpoints from several regions is a useful addition. On the frontend, real-user measurements of Core Web Vitals show how fast your site is for actual visitors. Our post on performance budgets explains how to turn those into firm limits.

Alerts people take seriously

Alert on symptoms

Alert on what users feel: rising error rates, slow responses, failed orders. A brief CPU spike with no user impact belongs on a dashboard, not in a 3 a.m. page.

Define targets

Service level objectives (SLOs) state the availability and speed you aim for. An alert fires when you are burning through that target too quickly. This cuts false alarms noticeably.

Make deployments visible

Mark every deployment on your dashboards. Many incidents start with a release, and a marker on the chart saves a long search. Our post on CI/CD pipelines covers how to automate deployments cleanly.

Data protection in logs and monitoring

Logs quickly collect personal data: IP addresses, email addresses, sometimes whole form submissions. Under GDPR you need a legal basis, clear retention periods and, for external services, a data processing agreement. In practice: never log passwords, tokens or payment data, truncate or pseudonymize IP addresses, delete logs after a fixed period and prefer providers that store data in the EU.

Frequently asked questions (FAQ)

When does a web application need monitoring?

From the first real user. At a minimum, uptime monitoring and error tracking should run from launch. Metrics, dashboards and traces follow as usage and complexity grow.

What does observability cost?

Almost entirely a function of data volume. Store every debug line and cloud providers get expensive quickly. Sensible log levels, trace sampling and short retention keep costs in check.

Isn't an uptime check enough?

No. An uptime check notices when your site is completely down. It does not notice that login fails for some users or that a page suddenly takes several seconds, and those are the more common problems.

Should we run monitoring ourselves or buy it?

For small teams a hosted service is usually more economical, because running your own stack takes time. Self-hosting makes sense when data protection rules require it or volumes are large enough to make services costly. With OpenTelemetry you stay flexible either way.

Conclusion

You can tell monitoring is working when your team spots problems before customers do and finds the cause in minutes rather than hours. A few well-chosen signals and alerts that fire only on real impact get you there. Our article on scaling web applications shows how this evolves as load grows. If you want to run a web application with confidence, talk to us about web development.