Events
The Events Explorer lets you search, visualize, and inspect operational events emitted in your WarpStream cluster. It is designed for troubleshooting and investigation. You can search recent activity, break it down over time, inspect full event payloads, and quickly pivot from one signal to another.
Depending on the page you are on, the explorer can be:
A full Events page that searches across the event types enabled for a cluster
An ACL-scoped explorer on the ACLs page
A pipeline-scoped explorer on the pipeline details page
Enabling events
Events must be enabled on a virtual cluster before they are available in the console or via the API.
Through the web UI
Navigate to your cluster in the WarpStream Console.
Open the cluster's Events tab.
Toggle events on.
Once enabled, events will begin flowing within a few seconds.
Through Terraform
Use the events attribute of the warpstream_virtual_cluster resource. See the Terraform provider documentation for the full schema.
What are events?
WarpStream events are JSON documents wrapped in a CloudEvents-style envelope. The top-level fields identify the event itself, and the nested data object contains the event-specific payload that you usually filter, group, and inspect in the UI.
Common top-level fields include:
specversion: the CloudEvents version, typically1.0id: a unique event IDsource: the component that emitted the event, such as an agent or control plane servicetype: the event category, such asagent_logs,acl_logs,pipeline_logs, ortableflow_logstime: the event timestampdatacontenttype: usuallyapplication/jsondata: the event payload
In practice, most searches focus on fields under data, such as data.log_level, data.message, data.operation, or data.pipeline_name.
Example ACL event
Notice the two layers:
The top-level envelope tells you when the event happened, where it came from, and what category it belongs to.
The nested
datapayload carries the fields you typically search on, such asdata.log_level,data.message,data.principal,data.operation,data.resource_type, anddata.resource_name.
Event types
The exact event types depend on the kind of cluster you are working with:
Kafka clusters typically expose
agent_logs,acl_logs, andpipeline_logsData lake clusters typically expose
agent_logsandtableflow_logs
The main event types are:
agent_logs: operational logs emitted by WarpStream agentsacl_logs: ACL authorization and denial activity for Kafka operationspipeline_logs: Bento and Orbit pipeline activity and errorstableflow_logs: Tableflow and data lake activity, such as ingestion and table lifecycle events
Not every event has the same fields. For example:
ACL events often include fields like
data.principal,data.operation,data.resource_type, anddata.resource_namePipeline events often include fields like
data.pipeline_name,data.stage, anddata.messageTableflow events often include fields like
data.type,data.table_name, anddata.table_uuid
Searching events
The basic search flow is:
Pick one or more event types when the page allows it.
Choose a time range.
Add filters in Builder mode or Raw mode.
Optionally enable the timeline and configure grouping or aggregation.
Run the search and inspect the detailed results.
The full Events page exposes the most controls. The ACL and pipeline variants reuse the same explorer but start from a narrower scope.
Time range
The explorer supports:
Quick relative ranges:
Last 5m,Last 15m,Last 1h,Last 4h, andLast 1dCalendar shortcuts:
TodayandYesterdayA custom relative duration
A single-day absolute time window
A local time / UTC toggle in the time picker
For safety and performance, event queries are limited to a maximum 24-hour window.
Filter modes
The explorer has two filter modes:
Builder mode: a structured UI for assembling filters from
field,operator, andvalueRaw mode: a text expression for advanced filtering
Builder mode is the easiest way to create straightforward comparisons. Raw mode is the right choice when you want more expressive filters, such as or, like, or in.
Builder mode also suggests fields and sample values based on recent results. Raw mode is best when you already know the fields you want to target.
Switching between Builder and Raw mode clears the other mode's current filter state, so it is best to pick one mode for a search and stay in it.
Query language
In Raw mode, you write only the filter expression. The rest of the query is generated for you by the explorer.
The filter language supports:
Comparisons:
==,!=,<,>,<=,>=Pattern matching:
like,not likeSet membership:
in,not inLogical operators:
and,orNested field access with dot notation, such as
data.resource_type
If you need to reference a top-level field name with special characters, wrap it in backticks, such as `field-name`.
Example filters:
Tips:
Most user-relevant fields live under
data, so filters often begin withdata.String values should be quoted
inandnot inuse square brackets
Preset queries
The explorer includes preset cards for common investigations. Depending on the page, these can prefill and immediately run a search with a combination of filter text, time range, grouping, and event type selection.
Examples include:
Warnings and Errors by TypeACL by OperationACL by Resource TypePipeline ErrorsPipeline WarningsEvents by Stage
Shareable URLs
The explorer stores its search state in the URL. You can share links that preserve your selected event types, time range, sort order, filter state, and timeline configuration.
Timeline and aggregations
The Show timeline toggle adds a chart view above the detailed results. This is useful for spotting spikes, bursts, or changes in event volume over time.
The timeline view supports:
Automatic time bucketing over the selected range
LinesorBarsdisplay modesGrouping by a field, such as
type,data.operation,data.resource_type, ordata.stageNumeric aggregations over a field using
Avg,Max,Min, orSum
When you group by a field, the chart can break the results into multiple series so you can compare categories over time. If there are too many distinct values, the chart keeps the most important series visible and groups the remainder into Other.
Detailed results
Below the timeline, the explorer shows a detailed event list.
Each result row shows a compact summary, including:
Timestamp
A one-line message
Event type
Log level when one is available
Clicking a row expands the full event details as JSON. From there, you can:
Expand all nested fields
Collapse the JSON view
Copy the full event payload
The detailed results view is optimized for interactive investigation:
Each search returns up to 100 detailed events
Results are progressively revealed 20 at a time as you scroll
A secondary in-results filter bar lets you narrow the current result set without re-running the backend query
The in-results filter bar is client-side only. It is useful when the main search has already returned the right time window and event family, and you just want to narrow the visible rows further.
Quick actions from JSON fields
The JSON details view is not just for inspection. Clicking a field name opens a context menu with quick actions such as:
Copy field name
Copy field value
Add a filter like
field == valueAdd a filter like
field != valueGroup the timeline by that field
This makes it easy to pivot from a single interesting event into a broader search or chart without manually typing the field path.
Scoped explorer variants
The same explorer appears in a few different places, with different levels of scope:
Global Events page: the full explorer, where you can search across the enabled event types for the cluster
ACLs page: an ACL-focused explorer that is already scoped to ACL events
Pipeline details page: a pipeline-focused explorer that is already scoped to the current pipeline
On the pipeline details page, the explorer applies the current pipeline name behind the scenes so searches stay focused on that pipeline. On the ACLs page, the explorer is limited to ACL events for the current cluster.
Limits and behavior
The explorer is intended for fast, interactive investigations, so it includes a few practical limits:
Queries are limited to a maximum 24-hour time range
The detailed results list returns up to 100 events per search
The timeline uses aggregated buckets rather than plotting every individual event directly
Those limits keep searches responsive while still making it easy to move from a broad signal to a specific event payload.
Last updated
Was this helpful?