Query history and usage for Elasticsearch

Every statement run from a worksheet is recorded with who ran it, where, how long it took and how many rows came back. The history is searchable, groupable and kept for as long as your plan allows.

What is recorded#

When a statement runs, FlatQL writes one history entry on its own servers (not on the cluster) with:

Result rows are not stored. The history holds the statement and its metrics, never the data it returned. Statements run in the desktop app are recorded locally and pushed to the same history, so the team view is complete whichever app people use.

Individual queries#

Open Query history from the rail. The default tab lists statements newest first with the user, connection, duration, row count and status. Filter by status (success or error) or by user, and search the SQL text; the search is a substring match, so orders finds every statement that mentions that index.

Click an entry for the detail page: the full statement, the duration, rows returned, the index or tables, when it started, and the Query DSL that was sent to the cluster for each index, as in the DSL view of a live result. A statement that produced an error shows the error text here too.

Grouped queries and fingerprints#

The Grouped queries tab collapses repeated statements. Two runs belong to the same group when they have the same fingerprint: the statement with every string literal and every number replaced by a placeholder, whitespace collapsed and case folded, then hashed. These two statements share one fingerprint:

SELECT COUNT(*) FROM orders WHERE currency = 'EUR' AND amount > 100;

SELECT COUNT(*) FROM orders WHERE currency = 'USD' AND amount > 250;

For each group over the last day, 7 days or 30 days you see the number of runs, how many failed, average and maximum duration, total rows, the users who ran it and the last run. Groups are sorted by run count, so the top of the list is what your team actually does with the cluster. A heavy statement that runs 400 times a day stands out here even when each run looks harmless on its own.

The detail page of any entry shows its fingerprint and Runs of the same shape, the count of entries sharing it.

Usage by user and connection#

Manage → Usage turns the same history into a chart. Pick the last 7, 30 or 90 days and view By user or By connection. Tiles at the top give queries, rows returned, total query time, errors, active users and connections used for the period; below them a stacked daily chart and a table per user (or connection) with the same numbers.

Usage is built from the history, so it reflects every statement, including ones that failed. There is nothing to configure on the cluster and no slow-log to parse.

Retention#

On the Free plan, entries older than a day disappear from the list, and opening an older detail link returns a message about the history window. Pro workspaces keep every entry for as long as the workspace exists. The history page states the current window under its title.

Who can see what#

• Owners and admins see every statement run by anyone in the team, on every connection, and the full usage view.
• Members see only their own statements. In the usage view they see only their own share; the by-connection view still shows the connections they used.

There is no setting that hides a statement from an owner or admin. If a team needs a record of who did what to a production cluster, this page plus the audit log are that record; the use case page on Elasticsearch query logging covers how this compares with the cluster's own slow log.

Limits#

The individual list shows the latest 200 entries that match the filters (the API allows up to 500). Grouped queries return up to 500 groups. The statement text is cut at 4,000 characters; the recorded plan, including the DSL, at 200 KB.