Health check endpoints in Express - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the output of this Express health check endpoint?

Consider this Express server code snippet for a health check endpoint. What will the client receive when requesting /health?

Express

import express from 'express';
const app = express();
app.get('/health', (req, res) => {
  res.status(200).json({ status: 'ok', uptime: process.uptime() });
});
// Assume server listens properly

A Plain text 'ok' with status 200

B {"status":"ok","uptime":<number>} (JSON with uptime as a number)

C 404 Not Found error

D 500 Internal Server Error

💡 Hint

Look at the response method used and the data sent in JSON format.

The endpoint responds with status 200 and a JSON object containing 'status' and 'uptime'. The uptime is a number representing seconds since the process started.

📝 Syntax

intermediate

Which option correctly defines a health check endpoint in Express?

You want to create a health check endpoint at /health that returns status 200 and JSON {"status":"healthy"}. Which code snippet is correct?

A app.get('/health', (req, res) => { res.status(200).json({ status: 'healthy' }); });

B app.get('/health', (req, res) => { res.status(200); res.json({ status: 'healthy' }); });

C app.get('/health', (req, res) => { res.sendStatus(200).json({ status: 'healthy' }); });

D app.get('/health', (req, res) => { res.json({ status: 'healthy' }).status(200); });

💡 Hint

Remember the order of chaining methods on the response object matters.

Calling res.status(200).json(...) sets the status and sends JSON in one chain. Option A calls json first then status, which does not set status correctly. Option A calls sendStatus which ends response, so json is invalid. Option A sets status but does not chain, so json sends with default status 200 anyway but chaining is preferred.

🔧 Debug

advanced

Why does this health check endpoint cause a runtime error?

Examine this code snippet for a health check endpoint. Why does it cause an error when accessed?

Express

app.get('/health', (req, res) => {
  res.status(200);
  res.json({ status: 'ok' });
  res.send('Healthy');
});

A res.status(200) is called without sending a response body, causing error.

B res.json cannot be called after res.status.

C Missing return statement causes the endpoint to hang and timeout.

D Calling res.send after res.json causes an error because response is already sent.

💡 Hint

Think about how many times you can send a response per request.

Once res.json sends the response, calling res.send again tries to send another response, which causes a runtime error because the response is already finished.

❓ state_output

advanced

What is the value of res.statusCode after this health check handler runs?

Given this Express health check handler, what will res.statusCode be after the function executes?

Express

app.get('/health', (req, res) => {
  res.status(503);
  res.json({ status: 'unavailable' });
});

A undefined

B 200

C 503

D 500

💡 Hint

res.status sets the status code before sending the response.

Calling res.status(503) sets the HTTP status code to 503. Then res.json sends the response with that status code. So res.statusCode is 503.

🧠 Conceptual

expert

Which option best explains why health check endpoints should be lightweight and fast?

Health check endpoints are often called frequently by load balancers or monitoring tools. Why is it important that these endpoints are lightweight and fast?

A Because slow or heavy health checks can cause false alarms and increase server load unnecessarily.

B Because health check endpoints must perform full database backups to verify system health.

C Because health check endpoints should block other requests until they finish.

D Because health check endpoints should always return detailed logs and metrics.

💡 Hint

Think about how frequent calls to health checks affect server performance and monitoring accuracy.

Health checks are called often to quickly verify if the server is alive. If they are slow or resource-heavy, they can overload the server or cause monitoring systems to think the server is down when it is just slow.