Skip to main content
Blaze’s four utility middleware modules cover the operational concerns that every production API needs: structured request logging, stable request identifiers for tracing, hard limits on handler duration, and security headers that browsers and scanners expect. Each module is a separate tree-shakeable import so you only bundle what you use.

Logger

logger() logs each request’s method, path, HTTP status, and response time to console.log. In the short format (default) it appends the Cloudflare colo code — the three-letter identifier of the datacenter that handled the request — making it easy to spot latency hotspots across regions.

LoggerOptions

logger() hooks into res.onSend() to capture the final status code and response time after your route handler completes — it adds no measurable latency to the request path.

Request ID

requestId() generates a UUID for each request using crypto.randomUUID(), attaches it to req.id, and sets it as the X-Request-Id response header. If the incoming request already carries an X-Request-Id header (e.g. forwarded from an upstream gateway), requestId() reuses that value rather than generating a new one — maintaining end-to-end trace continuity.

RequestIdOptions

Register requestId() before logger() so the request ID is available in log output:

Timeout

timeout() races the downstream handler chain against a timer. If the timer fires before your handler calls next() or sends a response, it calls next(new BlazeError(408, 'Request Timeout')) — routing to your error handler and returning 408 Request Timeout to the client. If the handler completes first, the timer is cancelled automatically.

TimeoutOptions

Cloudflare Workers already enforce a maximum CPU time per request (typically 50 ms on the free plan and up to 30 seconds on paid plans). timeout() is useful for keeping your own SLO well inside Cloudflare’s hard limit — for example, failing fast at 5 seconds on a plan with a 30-second wall clock limit so clients see a clean error instead of a Cloudflare edge timeout.

Secure headers

secureHdrs() sets a collection of security response headers that protect against common web vulnerabilities. All headers are pre-computed at middleware registration time (not on every request), so the per-request overhead is just a handful of Map lookups.

Default headers

Out of the box, secureHdrs() sets:

SecureHeadersOptions

Each header can be overridden with a custom string or disabled entirely by passing false. Options that are omitted use the default value from the table above; options with no listed default are not set unless you provide a value.
Combine all four utilities at the top of your app for a production-ready baseline: