For a fully worked example of querying a table directly, see the Activity page, which builds the exact SQL the dashboard runs.
How to read this page
Each table entry lists:- Written by — the pipeline stage that inserts rows
- Read by — the dashboard pages, agent, or APIs that query it
- Retention — the default TTL; all defaults are configurable per deployment on the Storage page
Event telemetry
The two raw kernel-event streams. Every other table on this page is derived from one of these.dag_events — Linux and cloud workloads
The primary event stream for Linux hosts and containerized workloads: one row per observed kernel event (exec, fork, file operations, network flows). Columns cover the categories described in Linux event data model — process and user identifiers, command line, file paths, network 5-tuples and byte counts, container/cgroup/Kubernetes context, and resolved workload and application identity.
endpoint_events — macOS devices
The native macOS event stream, one row per Apple Endpoint Security message, with code-signing trust (signing_id, code_signature, team_id, cdhash) and application attribution (application_id, application_display_name, responsible_pid, session_id) on every row. Fully documented in Event data model, including the complete column reference and event_type catalog.
dag_edr_events — macOS EDR findings
Curated security findings from the macOS EDR forwarder — one row per detection (persistence, tamper, credential access, removable media, network egress), each carrying severity, the MITRE ATT&CK technique, the acting process, and the agent’s response (blocked / alerted / logged). An incident_id column groups related findings into one attack chain.
Process and identity
Tables that reconstruct process lineage and resolve raw kernel identifiers into stable workload and application identities.Network
macOS network flows live directly in
endpoint_events (event_type = 'net_flow') — there is no separate flow table for macOS egress, since NetFilter resolves the responsible application at capture time.
Detection and anomalies
The output of the scoring pipeline. Scoring runs on a 5-minute epoch cadence per host.Detection combines three legs at different time scales: statistical z-score baselines (
dag_anomaly_scores, dag_anomaly_alerts), TRACE token-model scores (dag_trace_scores), and (when GNN_ENABLED and edge ingestion are on) GNN graph scoring. Token sequences, graph edges, and internal model state live in additional ClickHouse tables not listed here. They are implementation detail for the detection engine, not intended for direct query, and are deliberately excluded from this reference and from the anonymized export for the same reason detection rule logic is excluded — they describe your security posture.Hourly rollups
Pre-aggregated counters that keep fleet-wide dashboard widgets (like Overview) fast without scanning raw events. Each row is a per-host, per-hour aggregate — counts and byte sums, never individual event details.
Retention on hourly rollups is longer than the raw tables they summarize (typically 730 days), since they’re a fraction of the size.
Retention and storage tiers
Every table above lives in the hot tier (ClickHouse) while queryable, then moves to the cold tier (object storage) once its TTL is reached, per the tiering policy on the Storage page. Postgres holds a separate set of operational tables — user accounts, teams, detection rules, and HITL feedback — which are out of scope for this page; see Storage for the full tier breakdown including Postgres.Table and column names are stable within a major version but are an implementation detail of the current release. If you build tooling on direct SQL access, prefer the MCP server tools where possible — they present a stable interface across upgrades even when the underlying schema evolves.