Learn Angular - Observability & Monitoring

#Introduction

An application running in production is a black box without observability. You only find out the application is broken when users report it, even though the error already happened thousands of times in other users' browsers.

Episode 22 covers logging frontend errors and performance metrics, monitoring user interactions and page performance, error reporting with Sentry or LogRocket, and production support and incident handling. You'll build visibility into the application after it's released.

Observability isn't an add-on feature — it's part of the definition of "done". Without visibility, teams can neither measure quality nor find root causes quickly.

#Logging Frontend Errors and Performance Metrics

#Catching Global Errors

Angular has an ErrorHandler that can be replaced with a custom implementation to catch all unhandled errors:

Custom ErrorHandler

import { ErrorHandler, Injectable } from "@angular/core";
 
@Injectable()
export class GlobalErrorHandler implements ErrorHandler {
  handleError(error: unknown): void {
    console.error("[app] unhandled error", error);
    reportToObservability(error);
  }
}

Replace the default handler in the app providers with provide: ErrorHandler, useClass: GlobalErrorHandler. Errors that previously vanished in the console are now recorded in one place.

#Performance Metrics with the Performance API

Browsers provide PerformanceObserver for reading Core Web Vitals like LCP and CLS:

Measure LCP

function observeLcp(): void {
  new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      console.log("LCP", entry.startTime);
      sendMetric("lcp", entry.startTime);
    }
  }).observe({ type: "largest-contentful-paint", buffered: true });
}

These metrics give you a real picture of the user experience, not just guesses from local testing.

#Monitoring User Interactions and Page Performance

#Real User Monitoring

Real User Monitoring measures performance from real users' perspective. Initialization happens once in main.ts:

Initialize monitoring

import { enableProdMode } from "@angular/core";
import { bootstrapApplication } from "@angular/platform-browser";
import { AppComponent } from "./app/app.component";
import { appConfig } from "./app/app.config";
 
bootstrapApplication(AppComponent, appConfig)
  .catch((err) => console.error(err));

The data collected includes page render time, user interactions, and user journeys through the application. Slow page patterns or buttons that frequently fail become clearly visible.

#Catching HTTP Errors

An interceptor is the right place to record every failed request along with its status:

Error-logging interceptor

import { HttpInterceptorFn } from "@angular/common/http";
import { catchError, throwError } from "rxjs";
 
export const logInterceptor: HttpInterceptorFn = (req, next) => {
  return next(req).pipe(
    catchError((error) => {
      console.error("HTTP error", req.url, error.status);
      return throwError(() => error);
    })
  );
};

Combine this with a retry policy so transient errors don't disturb users, and only genuinely persistent errors reach the observability tool.

#Error Reporting with Sentry or LogRocket

#Installing Sentry

Sentry automatically collects stack traces, context, and affected users:

npm install @sentry/angular @sentry/core

Initialize Sentry before the application runs, then register the ErrorHandler from @sentry/angular so Angular errors are forwarded to Sentry. Every error comes with breadcrumbs — the sequence of user actions before the error occurred.

#LogRocket for Session Replay

LogRocket records user sessions, including the console, network requests, and application state. This feature is very helpful for debugging hard-to-reproduce issues: you don't just see a stack trace, you also see what the user actually did before the error appeared.

The combination of Sentry for errors and LogRocket for replay gives a complete picture: what broke and how the user got there.

#Production Support and Incident Handling

#Severity and Priority

Not all errors are equally important. Classify them by impact: an error blocking a transaction matters more than an error in a secondary feature. Sentry enables grouping and alerting based on severity so on-call engineers aren't flooded with notifications.

#The Incident Handling Flow

Prepare a runbook: how to identify the scope of an incident, find relevant logs, roll back the version, and communicate status. Performance metrics monitored in real time help decide whether an incident needs an immediate rollback or just observation.

A platform-level uptime check completes the whole system: if the server stops responding or the error rate spikes, the team is notified before users get the chance to report it.

#Wrap Up

Key takeaways:

• A custom ErrorHandler catches all unhandled errors.
• Core Web Vitals are measured with PerformanceObserver.
• Real User Monitoring measures the actual user experience.
• An interceptor logs HTTP errors along with their status.
• Sentry collects stack traces and breadcrumbs; LogRocket records sessions.
• Runbooks and alerting form a healthy incident-handling cycle.

In the next episode, episode 23, we'll cover stable modern features and future trends — standalone components, Signals, and standalone APIs, enterprise frontend trends, the Angular ecosystem with Material and the CDK, and strategies for keeping your Angular skills relevant.