Lesson 26 of 40 Operations Advanced 55 min

Health Checks & Observability

In this lesson, you will learn how to make applications easier to monitor, diagnose, and operate in production. Health checks tell you whether the app and its dependencies are functioning, while observability helps you understand what the system is doing over time.

← Back to Visual Studio 2026 Tutorial Home

What you will learn

What health checks are and how they differ from logging
How readiness and liveness checks serve different purposes
How logs, metrics, and traces fit together
How to expose health endpoints in ASP.NET Core
How to think like an operator, not just a developer

Why this matters: A system that works only when you are debugging locally is not enough. Production systems need visibility and operational feedback.

Part 1: Health checks in practice

Health checks provide a quick way to assess whether the application and its critical dependencies are working. In cloud and container environments, health endpoints are often used by orchestrators and load balancers.

builder.Services.AddHealthChecks()
    .AddSqlServer(connectionString)
    .AddCheck("self", () => HealthCheckResult.Healthy());

app.MapHealthChecks("/health");
    

A check may test database connectivity, cache availability, external APIs, or internal service state.

Part 2: Liveness vs readiness

Check type	Purpose
Liveness	Is the app process alive?
Readiness	Is the app ready to receive traffic?

An application may be alive but not ready, for example while starting up, reconnecting to dependencies, or performing initialization.

Part 3: Logs, metrics, and traces

Observability is broader than health checks. It usually rests on three pillars:

Logs: detailed event records and error details
Metrics: counters, timings, throughput, error rates
Traces: request flows across services and dependencies

Together, these let you answer not only “Is it up?” but also “Is it slow?”, “Where is the bottleneck?”, and “What failed first?”

Part 4: What to expose and what to protect

Health endpoints should be useful, but not overly revealing. In many systems, public endpoints expose only basic status, while internal dashboards provide more detailed diagnostics.

Good practice: Keep internal diagnostic detail available to operators, but avoid exposing sensitive implementation details publicly.

Part 5: Operational thinking

A reliable application should answer questions like:

Can the app respond to requests?
Can it reach its database, queue, or cache?
Is error rate rising?
Are requests slowing down?
Which dependency is causing failure?

Good observability design makes these questions easier to answer without guessing.

A practical observability workflow

Step 1: Expose a basic health endpoint

Step 2: Add dependency checks for critical services

Step 3: Structure logs clearly with useful context

Step 4: Track key metrics such as latency and error rate

Step 5: Add distributed tracing for multi-service systems

Step 6: Review observability as part of production readiness

Summary

In this lesson, you learned how health checks support operational readiness and how logs, metrics, and traces make applications truly observable.

In the next lesson, you will explore API versioning and evolution.