Exercises

Objectives

By the end of this lesson, you should be able to:

• Add a gauge metric, tracking a value that goes up and down, not just a running total
• Combine a health check route with a metrics endpoint
• Explain what uptime checks and alerting add on top of a /metrics endpoint

⚠️ A note on verification: the metrics code in this lesson was actually run. Uptime checks and alerting require a real, external monitoring service this course’s sandboxed tooling has no access to, that section reflects stable, current, documented practice.

Exercise: A Gauge for Dependency Health

a) Counters (Lesson 2) only increase, a Gauge is the metric type for a value that goes up and down, exactly right for something like “is the database currently reachable”:

const client = require('prom-client');

const dbHealthGauge = new client.Gauge({
  name: 'database_up',
  help: '1 if the database connection is healthy, 0 otherwise',
  registers: [register]
});

b) Confirm it reflects a changing value:

dbHealthGauge.set(1);
let text = await register.metrics();
console.log('healthy:', text.split('\n').find(l => l.startsWith('database_up ')));

dbHealthGauge.set(0);
text = await register.metrics();
console.log('unhealthy:', text.split('\n').find(l => l.startsWith('database_up ')));

healthy: database_up 1
unhealthy: database_up 0

Unlike http_requests_total, this value moves in both directions, exactly matching the real state it represents, a monitoring system watching database_up can alert the moment it drops to 0, rather than needing to infer a database problem indirectly from rising error rates elsewhere.

c) Combine a health check with metrics in one small app: a /health route (Module 5) that also updates database_up, and a /metrics route (Lesson 3) exposing it alongside request counters and duration histograms.

d) Uptime checks and alerting. A /metrics endpoint, scraped periodically, is what a monitoring system uses to build dashboards and detect trends. An uptime check is simpler and more immediate, an external service (UptimeRobot, Better Uptime, a cloud platform’s own built-in check, among many others) hitting a public URL, often /health, every minute or so, from outside the application’s own infrastructure entirely, if it stops getting a successful response, it alerts a team directly, by email, SMS, or a chat message. This is deliberately simple and independent of the application’s own metrics pipeline, if the whole metrics system itself is down, an external uptime check still works, since it doesn’t depend on anything internal to the application at all.

e) Reflect. Explain, in one or two sentences, why an uptime check hitting /health from an external service is a meaningfully different signal than the /metrics endpoint’s own request counters, even though both could theoretically detect “the application is having a bad day.”

Recap

This module gave a running application real, working observability: distinguishing what logs, metrics, and traces each answer, instrumenting real routes with counters and histograms confirmed against real, sent traffic, a /metrics endpoint in the standard format a monitoring system scrapes, and gauges for values, like a database connection’s health, that move in both directions. Combined with Course 3’s structured logging, this track’s Notes API is now genuinely observable, not just correct and running.

Next module: the capstone, bringing every module in this course together, deploying a complete, production-ready API, start to finish.