API monitoring that stays out of the request path
Midline records every request your API handles, with its method, route, status and timing, and puts the failures in front of you as issues. It watches from the side, so a problem with Midline can never become a problem with your API.
What gets recorded for every request
The always-on fields are the ones you need to answer "what happened and how long did it take". Anything more sensitive is opt-in.
- Always: method, route, status code and response time.
- Opt-in: headers, query parameters and bodies.
- A query string is never part of the route, so /orders?id=42 and /orders?id=43 are one route.
- Every request gets a request id and a correlation id, and a W3C traceparent header becomes a trace id.
Live numbers, from the same events as the rows
Requests per second, error rate, and average and p95 latency are calculated over a rolling window from the same events you see in the log, so the chart and the rows can never disagree.
Monitoring that fails open
The agent writes an event after the response has been handed to the socket, queues it in a bounded in-memory buffer and sends batches in the background. If Midline is slow, unreachable or misconfigured, events wait and retry with exponential backoff, and your responses go out as usual.
- Batches of up to 100 events, flushed every 1.5 seconds.
- A full queue drops the oldest events first, never your requests.
- A wrong API key switches the agent off after one log line instead of retrying forever.
Three ways to connect
Use whichever fits the service. All three land on the same stream.
- Node.js, Express or NestJS: add the middleware.
- Any language: run the reverse proxy in front of the API, no code changes.
- Anything that can make an HTTP request: post events, singly or in batches of up to 500.
Secrets are masked before they leave your process
Authorization headers, cookies, API keys and any field named like a password or token are masked at any depth. Bearer tokens, JWTs and Stripe or AWS keys hiding inside an error message or stack trace are caught too, and the server redacts again on ingest.
import express from "express";
import { MidlineAgent, midlineMiddleware, midlineErrorHandler } from "midline-agent";
MidlineAgent.init({
apiKey: process.env.MIDLINE_API_KEY,
serviceName: "checkout-api",
environment: process.env.NODE_ENV,
});
const app = express();
app.use(midlineMiddleware()); // before your routes
app.use(express.json());
// ...your routes
app.use(midlineErrorHandler()); // after your routes
app.listen(3000);
Questions
What is API monitoring?
API monitoring is recording what your API does in production: which requests arrive, how long they take, which ones fail and why. It turns "a customer says checkout is broken" into a specific route, status code and time.
Will Midline slow my API down?
Events are recorded after the response has been handed to the socket and sent in batches in the background, so nothing your user is waiting on touches the network. If Midline is unreachable, the agent buffers and retries while your API keeps serving.
Can I monitor an API that is not written in Node.js?
Yes. Run the Midline reverse proxy in front of the API, or post events to the HTTP ingest endpoint from any language. Django, FastAPI, Go, Java, PHP, Ruby and .NET services all report the same way.
Is there a free plan?
Yes. Starter is free and includes 1 organisation, 2 projects and 24 hours of log history. Every plan includes the agent, browser SDK, console capture and issues.
Quick start · Node.js agent · Ingest API
Start free