Health checks and monitoring in Deno - Step-by-Step Execution

Concept Flow - Health checks and monitoring

Start Server

↓

Health Check Endpoint Setup

↓

Receive Health Check Request

↓

Check System Status

↓

Healthy?

Yes→Return 200 OK

↓

No

→Return 503 Service Unavailable

↓

Monitoring Logs/Alerts

↓

Repeat Health Checks Periodically

The server starts and sets up a health check endpoint. When a request comes, it checks system status and returns 200 if healthy or 503 if not. Monitoring logs and alerts track these checks continuously.

Execution Sample

Deno

import { serve } from "https://deno.land/std/http/server.ts";

serve(req => {
  if (req.url.endsWith('/health')) {
    return new Response('OK', { status: 200 });
  }
  return new Response('Not Found', { status: 404 });
});

This code starts a Deno server that responds with 200 OK on '/health' requests and 404 otherwise.

Execution Table

Step	Request URL	Condition Checked	Response Status	Response Body
1	/health	req.url.endsWith('/health') == true	200	OK
2	/healthz	req.url.endsWith('/health') == false	404	Not Found
3	/health	req.url.endsWith('/health') == true	200	OK
4	/status	req.url.endsWith('/health') == false	404	Not Found
5	/health	req.url.endsWith('/health') == true	200	OK

💡 Server keeps running; each request is checked and responded to based on URL.

Variable Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5
req.url	undefined	/health	/healthz	/health	/status	/health
Condition (endsWith('/health'))	undefined	true	false	true	false	true
Response Status	undefined	200	404	200	404	200
Response Body	undefined	OK	Not Found	OK	Not Found	OK

Key Moments - 2 Insights

Why does the server return 404 for '/healthz' even though it looks similar to '/health'?

Because the condition checks if the URL ends exactly with '/health'. '/healthz' does not match this, so it returns 404 as shown in execution_table row 2.

Does the server stop after responding to one request?

No, the server keeps running and handles each request independently, as shown by multiple steps in the execution_table.

Visual Quiz - 3 Questions

Look at the execution table, what is the response status when the request URL is '/status'?

A 404

B 200

C 503

D 500

💡 Hint

Check execution_table row 4 where req.url is '/status' and see the Response Status column.

At which step does the condition req.url.endsWith('/health') evaluate to false for the first time?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Look at the Condition Checked column in execution_table to find the first false value.

If the condition changed to check req.url.includes('/health') instead, what would be the response status for '/healthz'?

A 404

B 200

C 503

D 500

💡 Hint

Consider that '/healthz' contains '/health' substring; check how includes() differs from endsWith() in variable_tracker.

Concept Snapshot

Health checks in Deno:
- Create an HTTP server with a '/health' endpoint.
- On '/health' requests, respond with 200 OK.
- For other URLs, respond with 404 Not Found.
- Use string methods like endsWith() to match URLs.
- Monitor responses to track server health continuously.

Full Transcript

This visual execution shows how a Deno server handles health check requests. The server listens for requests and checks if the URL ends with '/health'. If yes, it returns a 200 OK response; otherwise, it returns 404 Not Found. The execution table traces multiple requests showing how the condition and responses change. The variable tracker follows the request URL and condition evaluation step-by-step. Key moments clarify why similar URLs like '/healthz' do not match and that the server runs continuously. The quiz tests understanding of response codes and condition logic. This helps beginners see exactly how health checks work in a running server.

Practice

1. What is the main purpose of a health check endpoint in a Deno application?

easy

A. To verify if the application is running and responsive

B. To deploy the application to production

C. To increase the application's memory usage

D. To compile the Deno code into machine code

Solution

1. Step 1: Understand health check concept

   A health check endpoint is designed to confirm that the app is alive and responding to requests.

2. Step 2: Identify the correct purpose

   Options B, C, and D describe unrelated tasks like deployment, resource usage, or compilation, which are not health checks.

3. Final Answer:

   To verify if the application is running and responsive -> Option A

4. Quick Check:

   Health check = Verify app responsiveness [OK]

Hint: Health checks confirm app is alive and responding [OK]

Common Mistakes:

• Confusing health checks with deployment steps
• Thinking health checks improve performance directly
• Mixing health checks with code compilation

2. Which of the following is the correct way to create a simple health check HTTP endpoint in Deno?

easy

A. import { serve } from "https://deno.land/std/http/server.ts";
serve(req => console.log(req), { port: 8000 });

B. import { listenAndServe } from "https://deno.land/std/http/server.ts";
listenAndServe(8000, () => console.log("OK"));

C. import { serve } from "https://deno.land/std/http/server.ts";
serve(() => console.log("OK"), { port: 8000 });

D. import { serve } from "https://deno.land/std/http/server.ts";
serve(req => new Response("OK"), { port: 8000 });

Solution

1. Step 1: Check correct import and usage

   import { serve } from "https://deno.land/std/http/server.ts"; serve(req => new Response("OK"), { port: 8000 }); correctly imports 'serve' and returns a Response with "OK" for each request, which is a valid health check endpoint.

2. Step 2: Identify incorrect usage in other options

   import { listenAndServe } from "https://deno.land/std/http/server.ts"; listenAndServe(8000, () => console.log("OK")); uses deprecated 'listenAndServe' and does not respond to requests properly. Options A and C use console.log instead of returning a Response, so they won't respond correctly.

3. Final Answer:

   import { serve } from "https://deno.land/std/http/server.ts"; serve(req => new Response("OK"), { port: 8000 }); -> Option D

4. Quick Check:

   serve + Response("OK") = Correct health endpoint [OK]

Hint: Use serve with a Response object to reply to requests [OK]

Common Mistakes:

• Using console.log instead of returning Response
• Using deprecated functions like listenAndServe
• Not returning a response to HTTP requests

3. Given this Deno code snippet for a health check endpoint, what will be the output when accessed via HTTP?

import { serve } from "https://deno.land/std/http/server.ts";
serve(req => {
  if (new URL(req.url).pathname === "/health") {
    return new Response("Healthy", { status: 200 });
  } else {
    return new Response("Not Found", { status: 404 });
  }
}, { port: 8080 });

medium

A. Response with body 'Healthy' and status 404 when URL is '/health'

B. Response with body 'Healthy' and status 200 when URL is '/health'

C. Response with body 'Not Found' and status 200 for all URLs

D. Server crashes due to syntax error

Solution

1. Step 1: Analyze request URL condition

   The code checks if the request URL is exactly '/health'. If yes, it returns a 200 status with "Healthy".

2. Step 2: Understand else branch

   If the URL is anything else, it returns a 404 status with "Not Found".

3. Final Answer:

   Response with body 'Healthy' and status 200 when URL is '/health' -> Option B

4. Quick Check:

   URL '/health' = 200 Healthy [OK]

Hint: Check URL condition to predict response status and body [OK]

Common Mistakes:

• Confusing status codes for different URLs
• Assuming server crashes without syntax errors
• Mixing response body and status code

4. You wrote this Deno health check server code but it does not respond to requests properly. What is the error?

import { serve } from "https://deno.land/std/http/server.ts";
serve(req => {
  console.log("Received request");
});

medium

A. The serve function requires a port number as a string

B. The import statement is incorrect

C. The handler does not return a Response object

D. console.log is not allowed inside serve

Solution

1. Step 1: Check handler function

   The handler function only logs to console but does not return any Response, so HTTP requests get no valid reply.

2. Step 2: Verify other parts

   The import is correct, serve accepts an options object for port, and console.log is allowed. The main issue is missing Response return.

3. Final Answer:

   The handler does not return a Response object -> Option C

4. Quick Check:

   Handler must return Response [OK]

Hint: Always return a Response object in serve handler [OK]

Common Mistakes:

• Forgetting to return Response in handler
• Thinking console.log sends HTTP response
• Misunderstanding serve function parameters

5. You want to monitor your Deno app's health and expose metrics like uptime and request count. Which approach best combines health checks and monitoring in one server?

hard

A. Create two endpoints: '/health' returns 200 OK; '/metrics' returns JSON with uptime and request count

B. Use only '/health' endpoint returning plain text 'OK' without metrics

C. Create a single endpoint that returns HTML with uptime but no status code

D. Run two separate Deno servers, one for health and one for metrics, on different ports

Solution

1. Step 1: Understand combined health and monitoring needs

   Health checks confirm app is alive; monitoring provides metrics like uptime and request count.

2. Step 2: Evaluate options for best practice

   Create two endpoints: '/health' returns 200 OK; '/metrics' returns JSON with uptime and request count cleanly separates concerns with '/health' for status and '/metrics' for detailed data, both accessible on one server.

3. Step 3: Reject less effective options

   Use only '/health' endpoint returning plain text 'OK' without metrics lacks metrics, C lacks proper status code, D adds complexity by running two servers unnecessarily.

4. Final Answer:

   Create two endpoints: '/health' returns 200 OK; '/metrics' returns JSON with uptime and request count -> Option A

5. Quick Check:

   Separate endpoints for health and metrics = Best practice [OK]

Hint: Use separate endpoints for health and metrics on same server [OK]

Common Mistakes:

• Mixing metrics and health in one endpoint without status code
• Ignoring metrics in health checks
• Running multiple servers unnecessarily