Know what your Node.js API did.
Before your customers tell you.

Cloudflare decides whether a request gets in. We record what happened after it did.

Those are different jobs, and the gap between them is where most API incidents live. Your edge sees strangers - unknown IPs, bad signatures, known-bad patterns - and it’s good at that. What it can’t see is a legitimate, authenticated key behaving unlike itself: enumerating IDs one at a time, pulling fifty times its normal volume on a Sunday, or walking endpoints it has never touched before. That traffic passes every edge check, because it’s a customer.

Keep Cloudflare. We’re the layer inside your app where the caller has a name, a history, and a bill. The full comparison says what each one does better.

Datadog is a much broader product. If you need to monitor a Kafka cluster, build custom dashboards for forty services, and correlate across your whole estate, use Datadog - we’re not that, and we’re not trying to be.

We answer one question well: who called your API, and what happened. Because logging, timing, and screening run in one middleware, you get one record per request with the trace and the security verdict already on it. Nothing to correlate by request ID across three products and three clocks at 2am.

The other difference is structural. There’s no host agent to deploy, so there’s no per-host meter and no bill that grows every time you add a container.

What we don’t do: infrastructure monitoring, RUM, log ingestion from things that aren’t your API, or 800 integrations. The full comparison covers pricing and running both.

Fair question, and the right one to ask about middleware in a single-threaded runtime.

Nothing that matters runs on your request path. We capture metadata in-process, hand it to a buffer, and ship batches asynchronously off the event loop. No network call, no serialisation of large payloads, and no synchronous work between your handler and the response.

Don’t take our word for it: the middleware is public on GitHub, so you can read exactly what runs on your request path - and measure it against your own service on staging before it goes anywhere near production.

No. The middleware fails open.

If our collector is unreachable, requests complete exactly as they would without us. Telemetry queues into a bounded in-memory buffer and is dropped once that buffer is full - it never grows without limit, and it never blocks a response. You lose visibility for the duration of the outage. You don’t lose traffic.

Enforcement is a separate question, and the answer is better than fail-open usually implies. Verdicts are evaluated in your process against the policy you last synced, not by calling us - so a rule that was live when the connection dropped is still live now. During an outage you stop receiving policy changes; you do not stop being protected. The kill switch works the same way: API_TRAFFIC_WAF_ENABLED=false takes effect without a deploy and without reaching us, which is the case that matters when we are the problem.

Yes, through the proxy URL - and the SDKs are Node because that is where we can go deepest.

For any other stack, generate a proxy URL for your bucket: the same URL as your API call with only the hostname changed. Calls sent through it land in your request log, searchable, grouped by endpoint and watched by alerting, from any language and with no code to install.

The SDKs add what only an in-process middleware can see: your route definitions (/users/:id as one endpoint instead of forty thousand paths), the outbound calls your app makes, the queries behind each request, and a firewall that inspects the parsed request. That is why the first-party SDKs are for Node frameworks.

You decide what is kept, and the secrets are masked before you configure anything.

From the very first request, credential headers - Authorization, cookies, API key and CSRF headers - and secret-looking keys in bodies and query strings are masked inside your process, before anything is sent.

On top of that, redaction rules mask your own fields, either in your app so the value never leaves your server or on our side just before storage. Exclusion rules keep a route out entirely, or log its requests without their bodies. Everything you see afterwards - the request log, share links, embeds, the API and the MCP server - sees only the redacted value.

Keep them. Application logs are what your code chose to say. We record what actually crossed the wire.

The difference shows up on the requests you didn’t write a log line for: the ones that 404’d before reaching a handler, the ones that failed auth, the ones hitting a route someone shipped last quarter and forgot. Those don’t appear in your app logs precisely because your code never ran - and they’re disproportionately the ones worth looking at.

There’s also no correlation step. The timing and the verdict are already on the record; you’re not grepping a log drain and joining it to something else by hand.

The middleware is public on GitHub if you’d rather read it than take our word for what it does on the request path.

ApiTraffic tells you - alerts are on every plan.

Every endpoint is compared with its own normal, and a change has to be a multiple of normal, big in real terms and statistically real before anyone is told. Related alerts become one incident, sent to Slack, email, PagerDuty, Jira or a webhook following your routing. Each alert says why it was grouped, traffic alerts link straight to the requests behind them, and an alert that needs its own owner can be split into an incident of its own. Drift detection adds breaking API changes, certificate monitoring warns you before the certificate of a host your API calls expires, and deploy markers let you see which release changed what. How alerting works