Metrics & Governance
Log Explore
The Logs page explores any table that has a timestamp column — application
logs, audit tables, event streams, order history — with a time histogram,
filters and a live tail. You never type SQL, but everything it runs is a plain
SELECT against your source.
And when a search turns out to be one you’d rather be told about than go looking for, Save as alert turns it into an alert that fires on “N matches in a window”.
Explore a log table, step by step
Section titled “Explore a log table, step by step”Choose a source, table and time column, then a time window.
Open Logs. Choose the source, schema and table that hold your log rows.

Pick the time column and a window (15 minutes to 30 days). DataSquares draws a histogram of rows over time with the matching rows below it.

Save as alert turns the current search into an alert rule that fires when the number of matching rows crosses a threshold.

Pick what to explore
Section titled “Pick what to explore”Four dropdowns, each populated from the one before it (all start at select…):
| Control | What it lists |
|---|---|
| Source | your connected data sources |
| Schema | schemas in that source |
| Table | tables in that schema |
| Time column | the table’s date and timestamp columns |
Time column lists only the columns whose type is a date or a timestamp; a table with none says This table has no date or timestamp column to explore by., and the API refuses any other column as the time column. Nothing is preselected; you pick it. The search runs once all four are set. Until then: “Pick a source, table and time column to start exploring.”
Time range
Section titled “Time range”Five presets — 15m, 1h, 24h, 7d, 30d. The default is 24h. Choose Custom to enter fixed From and To date-times. A custom window disables Live tail because its end time does not move.
The histogram bucket follows the preset automatically; you don’t choose it:
| Range | Bucket |
|---|---|
| 15m, 1h | per minute |
| 24h, 7d | per hour |
| 30d | per day |
Custom windows bucket automatically too: up to two hours per minute, up to three days per hour, and longer windows per day.
The backend treats every window as from inclusive, to exclusive ([from, to)). Presets add one minute of forward clock-skew allowance to “now”; custom
windows use the exact date-times entered.
Above the histogram you get the match count and the bucket —
1,204 matches · per hour — and each bar’s tooltip reads {bucket}: {count}.
An empty window says “no matches in this window”.
Filters
Section titled “Filters”Pick a column from + filter…, choose an operator, type a value and press Enter. (There’s no Add button — Enter commits it.)
The operators are the raw codes:
| Op | Means |
|---|---|
eq / neq |
equals / does not equal |
contains |
substring match — the value appears anywhere in the column, character for character (the default) |
gt / gte / lt / lte |
greater / less than, and their or-equal forms |
contains takes the value literally: %, _, [ and \ in it are ordinary
characters, not wildcards, so 100% finds the rows that hold 100%, not every
row with 1000 in it — the same test a dashboard filter’s Contains runs on
that source. A saved alert counts with it too.
Whether letter case has to match is the source’s own rule, set by the column’s
collation: MySQL, MariaDB, SingleStore and SQL Server ignore case under their
default collations, so error also finds ERROR there; PostgreSQL, ClickHouse,
BigQuery and most other databases match case exactly.
Each committed filter becomes a chip — level eq error — with an X to
remove it. The API accepts up to 12 chips and every one narrows both the
histogram and the rows. A value that looks numeric is sent as a number, not a
string. The current UI does not pre-disable a thirteenth chip; the API rejects
the request instead.
You can also click a non-empty value in the results table to add an eq chip
for that column and value. Clicking the same value again does not add a
duplicate chip. Use the + filter… row for other operators.
Live tail
Section titled “Live tail”Live tail flips to Tailing and re-runs the search every 5 seconds. It is available for preset ranges and disabled for a custom fixed window.
It does not lengthen the window — it slides it. Pick 15m and turn on Live tail and you get a rolling trailing 15 minutes, refreshed every five seconds. Turn it off to freeze the window.
The rows
Section titled “The rows”Below the histogram you get the most recent matching rows, newest first, all columns. A row-limit control sets how many: 100 (the default), 500, 1,000 or 5,000. An empty result reads “No rows in this window.”
Save as alert
Section titled “Save as alert”Press Save as alert to turn the current search — source, table, time column, and the filter chips you’ve added — into an alert.
The Save search as alert dialog asks for four things:
| Field | Default |
|---|---|
| Alert name | — (e.g. “Error spike”) |
| Matches are | ≥ (also >, =, ≤, <) |
| Threshold | 10 |
| Window (min) | 15 (max 10080 — one week) |
So the default alert reads: fire when there are ≥ 10 matching rows in the trailing 15 minutes. The value compared against your threshold is the match count over that trailing window — the same count the histogram shows, re-evaluated server-side.
The alert is created immediately and evaluated every 15 minutes on the server, whether or not you’re logged in. Notification channels are the ones you already use — the bell, email, and Slack webhooks. You can’t set the schedule or the channels from this dialog.
Where the alert lives
Section titled “Where the alert lives”The new alert appears on the Home page’s Alerts card and in the dedicated Alert rules registry. Home offers pause/resume and delete for the first few rules. Alert rules adds search, active/paused and type filters, schedule and firing history, recipient editing, pause/resume, and deletion according to dashboard permissions. When it fires, the event appears in the activity/notification surfaces and goes out through configured channels; see Alert rules for the shared alert lifecycle.
Who can use it
Section titled “Who can use it”Access to the Logs page is a menu permission (logs), not a licensed
add-on, and the explore API checks the same permission. An API key additionally needs source:read, because it reads
source metadata and rows. Admins can grant the menu per role like any other
page.
Two access limits are worth knowing before you rely on it:
- Row-level security fails closed. Log Explore reads raw source tables, which bypasses the semantic model — and RLS is enforced in the model. So if any RLS policy applies to your account for that source, the search is refused outright: Logs can’t be explored on this source for your account (the API’s words: “Row-level-security policies apply to your account for this source — raw log explore cannot enforce them.”). This is deliberate: it would rather show you nothing than show you rows you shouldn’t see.
- Creating an alert needs dashboard-create permission. The Save as alert button is enabled for anyone who can reach a configured search, but the underlying alert API requires Dashboards → create. Without it, Create alert returns a permission error. Its creator can always update, pause or delete an alert; anyone else needs dashboard-update permission to update or pause it and dashboard-delete permission to delete it.
Identifiers are allowlisted and quoted by source dialect, filter values are escaped by the actual source driver family, and timestamps must be ISO-like. The endpoint runs only two read-only statements in parallel: a grouped histogram and newest-first rows. The selected row limit is enforced by the driver and capped at 5,000.
Related
Section titled “Related”- Audit log — the platform’s own governance trail, which is a different thing from exploring your log data here.
- Alert rules — how alerts are evaluated, fired and delivered.
- Webhooks — routing
alert.firedto Slack or your own endpoint. - SQL editor — when you do want to write the query yourself.