Monitor Unkey with Sazabi: Key Verifications, Audit Logs

Last verified on Nov 8, 2026.

Unkey sits in front of your API's most sensitive decisions: is this key valid, is this caller over the limit, who just deleted a key. The answers are events, and Unkey keeps most of them for a limited time. A question about last quarter's abuse may have no data left to answer it.

Sazabi, the AI-native observability and security platform, takes those events through an Unkey HTTP log drain. There is no agent or sidecar to run. Unkey posts batches to your Sazabi intake URL.

What each source sends

Unkey streams reach Sazabi through one method, and the data flows one way. A log drain posts to your intake URL as JSON or NDJSON. According to the Sazabi docs for this source, the streams are key verifications, rate limit decisions, audit logs, gateway HTTP requests and runtime logs.

Unkey's log drain page describes each one:

Key verifications: results of verifying API keys, filterable by keyspace and by outcome, such as VALID, RATE_LIMITED or EXPIRED.
Rate limits: pass or block decisions from rate-limit checks, filterable by namespace and by result.
Audit logs: workspace change events named resource.action, for example key.create, key.delete or logdrain.create.
Gateway HTTP requests: requests your Compute gateway handled, filterable by status class from 2xx to 5xx.
Runtime logs: application log lines from Compute, filterable by severity from error to debug.

Each log drain sends exactly one stream. For two streams you create two log drains. A new log drain does not backfill, so it sends only events from the moment you create it. Filters apply from the log drain's current position, not retroactively.

Delivery details matter for duplicates. Unkey retries a failed batch, and a delivery counts only when the destination returns 2xx within 30 seconds. Retries can repeat events. Unkey names the field to deduplicate on: id for audit logs, request_id for key verifications and gateway requests, log_id for runtime logs.

One practical blocker is documented too. Every Unkey plan starts with a log drains limit of 0, so you must ask Unkey support to raise it before the form will let you create one.

Questions it answers

Which keys were rejected as RATE_LIMITED in the last 24 hours, and from which keyspace?
Who deleted a key, and when? (key.delete in the audit logs)
Did a deploy change the share of 5xx gateway responses?
Which rate-limit namespace blocks the most calls?
Did an EXPIRED key keep calling after its expiry date?
Which events were delivered twice because of a retry?

A worked example: a key that was deleted and still tried

A customer says their integration broke on Tuesday. Your key store shows the key is gone. You want to know who removed it and what the caller did afterwards. That takes two streams: audit logs for the removal, key verifications for the later calls. Unkey keeps each for up to 90 days, but a log drain only collects events from the day you create it. Set the drains up before you need them.

Ask the Sazabi agent in a thread:

Find the Unkey audit log event key.delete for the key used by this customer,
then list key verifications for the same key after that time with their outcomes.

You are looking for two things. First, the time of the key.delete event. A deletion at 14

, followed by failed verifications at 14

, tells you the cause is your own change and not an attack. Second, repeated failures long after the deletion tell you the customer's code never handled the rejection, so a note to them is the fix. If the audit log has no key.delete at all, the key may have expired. Compare against EXPIRED outcomes.

Sizing the streams

Gateway requests and runtime logs can be high volume. Unkey's filters trim them before they leave: choose HTTP statuses to send only 5xx, or pick Severity error and warn. Leave a filter empty to send everything, including values added later.

How it fits with other integrations

Unkey belongs to the security category. Its gateway logs make most sense next to your own service logs from AWS or Cloudflare, where the same request may also appear. If your runtime uses OpenTelemetry, the OpenTelemetry integration covers that side, and pricing explains how event volume is counted.

Log sources

Unkey (manual log source, security): Add an HTTP log drain in the Unkey dashboard pointed at your Sazabi intake URL to forward API key verifications, rate limits, audit logs, gateway requests, and runtime logs.

Frequently Asked Questions

Why can I not create a log drain in Unkey?

Every Unkey plan starts with a log drains limit of 0, so Settings > Log Drains will not let you create one. Unkey says to ask support to raise the limit for your workspace.

Does one log drain send everything?

No. Each log drain sends exactly one stream: key verifications, rate limits, audit logs, gateway HTTP requests or runtime logs. Create another log drain for each additional stream.

Will I see duplicate events?

Possibly. Unkey retries a failed batch, so a destination can receive the same event twice. Unkey names the field to deduplicate on: id for audit logs, request_id for key verifications and gateway requests, and log_id for runtime logs.

Are old Unkey events backfilled?

No. A new log drain only sends events that happen after you create it. Set log drains up early for streams Unkey retains for only 7 days or 1 month.

Sources

Connect Unkey to Sazabi