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, 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`, `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 (for example, succeeded or failed)
`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

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_events for 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