Skip to content

Reporting: Reports Over Your Stored Events

AuditFlow routes your events and keeps no database. Reporting is the read side: your backend asks for a named metric on behalf of one customer, and gets that customer's numbers, enforced in the query and again by a row policy on the server.

AlphaRuns, but is incomplete and has known gaps. Expect breaking changes.

No module has reached 1.0 yet.

A metric is a reviewed definition

A catalogue names the table, the aggregation, the dimensions and the filters. Adding a metric adds a catalogue entry, not an endpoint. A request picks names from it and never carries SQL; every value is a bound parameter.

One store, many customers

Every query filters on the caller's scope, and a ClickHouse row policy applies the same scope to a query that forgot. Your backend authenticates the customer and translates its plan into groups and days of history: the service knows no plan names.

Events, traces and bodies

Metrics by range and up to two dimensions, events paged by cursor, every event of one correlation ID, and an event's archived request and response from S3 when the plan allows it.

Read the documentation ยท Source on GitHub