Skip to content
datasquares.aiSign inStart free

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”.

Choose a source, table and time column, then a time window.

  1. Open Logs. Choose the source, schema and table that hold your log rows.

    Open Logs. Choose the source, schema and table that hold your log rows.
  2. 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.

    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.
  3. Save as alert turns the current search into an alert rule that fires when the number of matching rows crosses a threshold.

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

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.”

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”.

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 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.

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.”

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.

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.

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.

  • 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.fired to Slack or your own endpoint.
  • SQL editor — when you do want to write the query yourself.