Event contract
Fields the query expects
| Field | Type | Why it exists |
|---|---|---|
| timestamp_utc | Timestamp | Lifecycle event time. |
| key_id | Utf8 | Non-secret key record identifier. |
| owner_type | Utf8 | Service, user, or automation owner class. |
| scope_class | Utf8 | Bounded scope category. |
| event_name | Utf8 | key_created, key_used, key_rotated, or key_revoked. |
| outcome | Utf8 | success, denied, or failed. |
Copy the query
SELECT
key_id,
owner_type,
scope_class,
MIN(CASE WHEN event_name = 'key_created' THEN timestamp_utc END) AS created_at,
MAX(CASE WHEN event_name = 'key_used' THEN timestamp_utc END) AS last_used_at,
MAX(CASE WHEN event_name = 'key_rotated' THEN timestamp_utc END) AS rotated_at,
MAX(CASE WHEN event_name = 'key_revoked' THEN timestamp_utc END) AS revoked_at,
SUM(CASE WHEN outcome <> 'success' THEN 1 ELSE 0 END) AS failed_events
FROM api_key_audit_events
WHERE timestamp_utc >= now() - INTERVAL '90 days'
GROUP BY key_id, owner_type, scope_class
ORDER BY created_at;This read-only query is planned and executed against an empty typed table with Apache DataFusion 45.2.0. The deterministic sample output is synthetic and reviewed separately; validate field types, thresholds, and business definitions against your own data. Read the testing methodology.
Query result
API-key lifecycle review
The table preserves lifecycle timestamps and non-secret identifiers for review.
| key_id | owner_type | scope_class | created_at | last_used_at | rotated_at | revoked_at | failed_events |
|---|---|---|---|---|---|---|---|
| key-record-17 | automation | read-write | 2026-05-02 | 2026-07-28 | — | — | 0 |
| key-record-42 | service | write | 2026-07-01 | 2026-07-26 | 2026-07-27 | 2026-07-27 | 1 |
Synthetic example output. Run the query against your own event schema and thresholds before using it for operational decisions.
Reproduce the example
Download the public fixture
The JSON bundle includes the typed event contract, illustrative input rows, exact SQL, expected output, review notes, and engine version. The CSV contains the displayed result.
How the SQL works
- 1Conditional timestamps collapse a key lifecycle into one review row.
- 2A non-secret key record ID supports correlation without exposing key material.
- 3Failed lifecycle events remain visible beside terminal state.
Edge cases to decide
- Never log the key, token prefix, authorization header, or a reversible hash.
- Rotation can involve overlapping old and new keys.
- Retention and access to credential metadata need security approval.
Recommended dashboard
- Table: key lifecycle by owner class
- Stat: active keys without recent use
- Trend: failed rotation and revocation events
Alert guidance
Alert on failed revocation, unexpected post-revocation use, or a privileged key outside the approved rotation window.
Read alert setupPut the recipe to work
Related instrumentation and guides
Continue the analysis
Analyze Authentication Failure Rate
Measure authentication failures by method and reason while keeping traffic volume and affected identities visible.
Open recipeAudit Privileged Actions with SQL
Summarize sensitive administrative actions, denied attempts, and review-required outcomes without collecting raw secrets or resource contents.
Open recipeDetect Suspicious Authentication Bursts
Find short authentication windows with repeated failures across many identities or coarse network sources.
Open recipeRun it on real events
Create a table, adapt the fields, and save the result
Start free, send structured events, and use the query result as a chart, shared dashboard widget, or alert input.