Health check endpoints in Express - Deep Dive

Overview - Health check endpoints

What is it?

Health check endpoints are special URLs in a web application that tell if the app is running well. They respond quickly to requests, showing if the app is alive and ready to handle traffic. These endpoints usually return simple messages or status codes. They help keep the app reliable and easy to monitor.

Why it matters

Without health check endpoints, it is hard to know if an app is working properly without digging into logs or crashing users. They allow automatic systems to detect problems early and restart or fix the app before users notice. This keeps websites and services available and trustworthy.

Where it fits

Before learning health check endpoints, you should know basic Express app setup and routing. After this, you can learn about monitoring tools, load balancers, and deployment strategies that use these endpoints to keep apps healthy.

Mental Model

Core Idea

A health check endpoint is a simple doorbell that lets monitoring systems quickly check if your app is awake and ready.

Think of it like...

It's like a receptionist at an office who answers the phone with a quick 'Yes, we're open!' so callers know the office is ready to help.

┌─────────────────────┐
│ Client / Monitor     │
│ sends GET /health   │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ Express App          │
│ Health Check Handler │
│ responds 200 OK      │
└─────────────────────┘

Build-Up - 6 Steps

1

Foundation

What is a health check endpoint

Concept: Introduce the idea of a special URL that reports app status.

A health check endpoint is a URL like '/health' that responds with a simple message or status code. It tells if the app is running and reachable. For example, a GET request to '/health' might return 'OK' or a 200 status code.

Result

You understand that health check endpoints are simple URLs that say if the app is alive.

Understanding this basic concept helps you see how apps communicate their status to outside systems.

2

Foundation

Creating a basic health check in Express

Concept: Show how to add a simple route in Express for health checks.

In Express, you add a route like this: const express = require('express'); const app = express(); app.get('/health', (req, res) => { res.status(200).send('OK'); }); app.listen(3000); This code makes '/health' respond with 'OK' and status 200.

Result

Your Express app now has a working health check endpoint at '/health'.

Knowing how to add a simple route is the foundation for building reliable health checks.

3

Intermediate

Adding readiness and liveness checks

🤔Before reading on: do you think one health check URL is enough for all monitoring needs? Commit to yes or no.

Concept: Explain the difference between liveness and readiness endpoints.

Liveness checks tell if the app is alive (not crashed). Readiness checks tell if the app is ready to handle requests (e.g., database connected). You can add two endpoints: app.get('/health/live', (req, res) => res.sendStatus(200)); app.get('/health/ready', (req, res) => { if (databaseIsConnected()) { res.sendStatus(200); } else { res.sendStatus(503); } });

Result

Your app can now tell if it is alive and if it is ready to serve traffic separately.

Understanding these two types of checks helps prevent sending traffic to an app that is alive but not ready.

4

Intermediate

Checking dependencies in health endpoints

🤔Before reading on: do you think health checks should only check the app code or also external services? Commit to your answer.

Concept: Teach how to include checks for databases or other services in health endpoints.

Health checks often verify if important services like databases or caches are reachable. Example: function databaseIsConnected() { // check database connection status return true; // or false } app.get('/health/ready', (req, res) => { if (databaseIsConnected()) { res.sendStatus(200); } else { res.sendStatus(503); } });

Result

Health checks now reflect the real readiness of the app including its dependencies.

Knowing to check dependencies prevents false positives where the app is alive but can't serve real requests.

5

Advanced

Using health checks with load balancers

🤔Before reading on: do you think load balancers use health checks to decide where to send traffic? Commit to yes or no.

Concept: Explain how load balancers use health endpoints to route traffic only to healthy instances.

Load balancers periodically call health check URLs to see which app instances are healthy. If an instance returns failure, the load balancer stops sending it traffic until it recovers. This keeps users away from broken or overloaded servers.

Result

Your app's health checks help keep user traffic flowing only to working servers.

Understanding this shows why health checks must be fast and reliable to keep apps available.

6

Expert

Handling health check performance and security

🤔Before reading on: do you think health check endpoints should perform heavy checks or be lightweight? Commit to your answer.

Concept: Discuss best practices for making health checks fast, secure, and not resource-heavy.

Health checks should respond quickly to avoid slowing down monitoring. Heavy checks (like full database queries) can be cached or done less often. Also, health endpoints can expose info attackers might use, so protect them with IP filters or authentication if needed. Example: app.get('/health/ready', (req, res) => { if (cachedDbStatusIsGood()) { res.sendStatus(200); } else { res.sendStatus(503); } });

Result

Your health checks are efficient and secure, avoiding performance hits and leaks.

Knowing how to balance thoroughness with speed and security is key for production health checks.

Under the Hood

When a health check URL is requested, Express routes the request to the handler function. This function runs code to verify app status or dependencies, then sends an HTTP response. The HTTP status code (like 200 or 503) signals health. Monitoring tools interpret these codes to decide if the app is healthy. The process is lightweight and synchronous to ensure quick responses.

Why designed this way?

Health checks were designed to be simple and fast so monitoring systems can frequently check app status without adding load. They separate liveness and readiness to handle complex app states, like starting up or waiting for dependencies. This design evolved from the need to keep distributed systems reliable and self-healing.

┌───────────────┐
│ Monitor/Probe │
└──────┬────────┘
       │ HTTP GET /health
       ▼
┌───────────────┐
│ Express Router│
└──────┬────────┘
       │ Calls handler
       ▼
┌─────────────────────────────┐
│ Health Check Handler Logic   │
│ - Check app alive            │
│ - Check dependencies         │
│ - Return status code & body  │
└──────────────┬──────────────┘
               │
               ▼
       ┌───────────────┐
       │ HTTP Response │
       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does a 200 OK response always mean the app is fully ready? Commit to yes or no.

Common Belief: If the health check returns 200 OK, the app is fully healthy and ready.

Reality: A 200 OK might only mean the app process is running, not that all dependencies are ready.

Why it matters: Relying only on liveness can cause traffic to be sent to an app that can't serve requests properly, causing errors.

Quick: Should health checks perform heavy database queries every time? Commit to yes or no.

Common Belief: Health checks should do full deep checks every time to be accurate.

Reality: Heavy checks slow down responses and can overload the app; caching or lightweight checks are better.

Why it matters: Slow health checks can cause monitoring timeouts and false failure reports, reducing reliability.

Quick: Are health check endpoints always safe to expose publicly? Commit to yes or no.

Common Belief: Health check URLs are harmless and can be open to everyone.

Reality: They can reveal sensitive info or be abused; sometimes they need protection.

Why it matters: Exposing health endpoints without control can lead to security risks or denial of service.

Quick: Do load balancers always trust any health check response? Commit to yes or no.

Common Belief: Load balancers accept any response from health checks as valid.

Reality: Load balancers expect specific status codes and timeouts; unexpected responses cause failures.

Why it matters: Misconfigured health checks can cause load balancers to wrongly mark healthy instances as down.

Expert Zone

1

Health checks often use cached results for expensive dependency checks to balance accuracy and speed.

2

Some systems use separate endpoints for startup, liveness, and readiness to finely control traffic flow.

3

Health check failures can trigger automated recovery workflows, so their accuracy directly affects system resilience.

When NOT to use

Health check endpoints are not suitable for detailed diagnostics or debugging. For deep insights, use dedicated monitoring or logging tools. Also, avoid using health checks for business logic validation or user authentication.

Production Patterns

In production, health checks are integrated with orchestration tools like Kubernetes, which use readiness and liveness probes to manage pods. Load balancers like AWS ELB use these endpoints to route traffic. Caching dependency status and protecting endpoints with network policies are common practices.

Connections

Load Balancing

Health check endpoints provide the signals load balancers use to route traffic only to healthy servers.

Understanding health checks clarifies how load balancers maintain high availability by avoiding unhealthy instances.

Monitoring and Alerting Systems

Health checks feed monitoring tools with real-time app status data to trigger alerts or automated fixes.

Knowing health checks helps you design better monitoring that reacts quickly to real problems.

Human Immune System

Health checks are like the body's immune system signals that detect if something is wrong and trigger responses.

Seeing health checks as biological signals helps appreciate their role in keeping complex systems alive and responsive.

Common Pitfalls

#1 Health check performs a slow database query on every request.

Wrong approach:

app.get('/health', async (req, res) => {
const result = await db.query('SELECT 1');
res.status(200).send('OK');
});

Correct approach:

let cachedDbStatus = true;
setInterval(async () => {
cachedDbStatus = await checkDbConnection();
}, 10000);

app.get('/health', (req, res) => {
if (cachedDbStatus) {
res.status(200).send('OK');
} else {
res.status(503).send('DB not ready');
}
});

Root cause:

Misunderstanding that health checks must be fast and lightweight to avoid slowing the app and causing false failures.

#2 Using the same endpoint for liveness and readiness without checking dependencies.

Wrong approach:

app.get('/health', (req, res) => {
res.status(200).send('OK');
});

Correct approach:

app.get('/health/live', (req, res) => res.sendStatus(200));
app.get('/health/ready', (req, res) => {
if (dependenciesReady()) {
res.sendStatus(200);
} else {
res.sendStatus(503);
}
});

Root cause:

Not recognizing the difference between being alive and being ready to serve traffic.

#3 Leaving health check endpoints open without any access control.

Wrong approach:

app.get('/health', (req, res) => res.status(200).send('OK'));

Correct approach:

app.use('/health', ipFilterMiddleware);
app.get('/health', (req, res) => res.status(200).send('OK'));

Root cause:

Assuming health endpoints are harmless and forgetting security best practices.

Key Takeaways

Health check endpoints are simple URLs that tell if your app is alive and ready to serve traffic.

Separating liveness and readiness checks helps prevent sending users to apps that are alive but not ready.

Health checks should be fast and lightweight to avoid slowing down your app or causing false alarms.

In production, health checks integrate with load balancers and orchestration tools to keep apps available.

Protecting health check endpoints is important to avoid security risks and misuse.