In-Warehouse Log
Zeotap writes every operational outcome to an observability log table in your own data warehouse. Because the history lives in your warehouse, you can query it with SQL, join it against your other data, and build dashboards in whatever BI tool you already use — without leaving your data platform.
The in-warehouse log is on by default. There is nothing to enable.
Where the Log Lives
The log is written to the observability_events table in the audit_logs schema of your warehouse.
Zeotap writes it to your workspace’s configured event-log warehouse. If you have not designated one, it uses your first connected warehouse.
What Gets Logged
One row is written for each operational outcome across the platform — sync, journey, loader, store feed, realtime audience snapshot rebuild, identity graph, and trait runs, plus event delivery and contract activity. Both successful completions and failures are recorded, along with:
- Runs that stall and are later detected as failed
- Consecutive-failure signals
- Automatic-pause signals
Table Schema
Each row describes one observability event:
| Column | Description |
|---|---|
occurred_at | When the event happened |
event_type | The kind of event (for example, a run completion or failure) |
severity | Relative importance of the event |
resource_type | The type of resource (sync, journey, loader, store_feed, audience_snapshot, identity_graph, trait, and so on) |
resource_id | Identifier of the specific resource |
resource_name | Human-readable name of the resource |
run_id | Identifier of the run this event belongs to |
status | Outcome of the run — completed, failed or cancelled |
error_message | Failure detail, when the event represents a failure |
metrics | Structured metrics for the run (row counts, duration, rejected rows, and so on), stored as JSON |
attributes | Additional structured context, stored as JSON |
Column Values
status is completed, failed or cancelled. severity is info, warning or critical.
resource_type is one of sync, journey, loader, store_feed, identity_graph, trait, event_forwarding, contract, connection, warehouse or audience_snapshot.
event_type names the signal itself:
| Event type | What it records |
|---|---|
run.completed | A run finished cleanly |
run.failed | A run failed |
run.cancelled | A run was cancelled |
run.zombie | A run stopped heartbeating and was reclaimed |
run.deferred | A batched journey run was spilled to its journey’s next wake |
sync.consecutive_failures | A sync’s failure streak crossed its threshold |
sync.auto_paused | A sync was paused automatically after repeated failures |
sync.rows_capped | A run suppressed rows under a frequency cap |
connection.auth_expired | A connection’s stored credential stopped authenticating |
event.delivery_failed | An event delivery failed |
event.volume | Event volume for a window |
contract.violation | An event breached a contract |
snapshot.rebuilt | A realtime audience’s membership was rebuilt and served |
snapshot.held | A realtime audience’s new membership was set aside as unusually large |
journey.wake_skipped | A journey was due but could not start — an active run, or the workspace concurrency cap |
warehouse.reclaim_failed | Deleting a resource could not drop the warehouse objects it owned |
warehouse.objects_reaped | A reaper sweep dropped orphaned warehouse objects |
Realtime audiences write at two granularities under the one audience_snapshot resource type. run.* events carry the workspace id, because one rebuild scans for every audience at once; snapshot.rebuilt and snapshot.held carry the audience id, with that audience’s membership size and its enter and exit counts under metrics.
Example Queries
Failures in the last 24 hours, most recent first:
SELECT occurred_at, resource_type, resource_name, error_message
FROM audit_logs.observability_events
WHERE status = 'failed'
AND occurred_at >= CURRENT_TIMESTAMP - INTERVAL '24' HOUR
ORDER BY occurred_at DESC;Run counts by resource type and status over the last week:
SELECT resource_type,
status,
COUNT(*) AS runs
FROM audit_logs.observability_events
WHERE occurred_at >= CURRENT_TIMESTAMP - INTERVAL '7' DAY
GROUP BY resource_type, status
ORDER BY resource_type, status;The metrics and attributes columns are JSON — use your warehouse’s JSON functions to extract individual values (for example, row counts or duration).
Best Practices
- Build a health dashboard — Point your BI tool at
audit_logs.observability_eventsfor an always-current view of pipeline health, entirely within your own warehouse. - Keep it for trend analysis — Because the log persists in your warehouse, it is well suited to long-range trend analysis that live alerting does not cover.
- Pair it with alerting — Use the Alerting section for real-time notification, and the in-warehouse log for investigation and reporting after the fact.
Next Steps
- External Export (OTLP) — Stream telemetry to your monitoring platform
- Alerting — Turn these events into real-time notifications