What this project is about
When an application depends on several services, a simple operational question becomes difficult: which dependency is unavailable, and which is merely slow? Integration Monitor provides a Node.js service and browser dashboard that checks configured HTTP endpoints and presents current status, latency and recent observations. The default configuration can monitor the companion Ledger API's public health endpoint.
The project is deliberately lightweight, using Node's built-in server, fetch and test facilities with a vanilla JavaScript interface. It demonstrates a complete status-checking path without an external monitoring platform. Its evidence concerns local functionality and response contracts; there are no verified customer uptime figures, historical service-level reports or continuously operated alerting system.
How it works
- Allowlisted service targets
- Concurrent timed health checks
- Status + rolling history dashboard
Check dependencies concurrently
A request to the status API starts checks for the configured integrations concurrently. Each check makes an HTTP GET with a timeout and records elapsed time, status code and observation timestamp. Successful responses above the integration's latency threshold become degraded; faster successes are healthy. HTTP failures and transport errors become down. The threshold classifies a single observation, rather than calculating a long-term availability objective.
Expose current status with bounded history
The API returns current observations together with a short per-service history. New results are added at the front, and only the most recent twelve are retained. The browser renders service information through DOM APIs and textContent instead of treating it as HTML. Static responses include a restrictive content-security policy, and the JSON status response is marked not to be cached.
Control inputs and error disclosure
Targets are selected in server-side configuration; visitors cannot submit arbitrary destinations for the server to fetch. This avoids turning the dashboard into an open proxy. Error sanitisation removes URL user-information credentials, flattens control whitespace and limits message length. It is a targeted safeguard, not a general secret-detection system: arbitrary sensitive query parameters or upstream error details are not comprehensively classified.
The important design choices
Use configuration rather than public URL input
Keep the integration list under server-side control and expose a read-only status API.
The trade-offThe public interface is smaller and easier to review, but changing monitored services requires configuration access. A future administration interface would need authentication and destination validation.
Keep observations in memory
Maintain a bounded recent history inside the application process.
The trade-offThis is sufficient to demonstrate status changes with little setup. Restarts erase the history, multiple instances have separate records, and the data cannot support a durable audit or long-term uptime claim.
Distinguishing slow from unavailable
Two configured services are checked: one returns a successful response above its latency threshold, and another returns HTTP 503.
- The status request starts both checks concurrently and measures their response times separately.
- The slow successful result is marked degraded, while the unsuccessful HTTP response is marked down.
- Both observations appear in the JSON response and are added to each service's bounded recent history.
What this showsThe dashboard communicates two different operational symptoms without converting a slow response into an outage or claiming a historical availability percentage.
Illustrative example, not a production incident.
How it was tested—and what it shows
The checks
Unit tests check latency classification, mapping an upstream HTTP error to down, credential removal from an error message and history truncation. API regression tests start the real HTTP application on an ephemeral port with an injected checker. They verify the JSON response contract and rejection of unsupported methods. Controlled responses make these tests repeatable without relying on an external service remaining available.
What to take from the results
The project shows how a small backend and accessible dashboard can expose service health consistently. A significant limit is that checks are triggered by status requests, not an independent scheduler: observation frequency depends on callers. The health result also reflects HTTP success and elapsed time, not whether the upstream system completed a meaningful business operation or whether its database is ready.
What to keep in mind
- History is held in memory and is not a durable incident record.
- A health check shows what that endpoint did at a particular time, not everything about the service.
Technical notes & source
Built with
Node.js · vanilla JavaScript · built-in test runner
Terms used in this project
- Latency
- How long a request takes to receive a response.