Runs, queries and deploys lists

The three lists that show what happened in an environment: the filters of each, the order, the cursor that pages through it, who sees what, the commands, the SDK and the routes. For the steps, see Find a run, a query or a deploy.

The lists

Every filter narrows the list; filters combine with AND. A filter is never a way to see more than the list shows without it.

Filters

--since on the command line also takes a date (2026-10-18) or a time without a time zone, which is read in the time zone of your computer. The route needs the time zone: since=2026-10-18T09:30:00 is refused with 422.

A query status that has ended (succeeded, failed, cancelled) lists the queries that ended in the last 24 hours, with or without --all. The list never shows older ones.

Paging

--limit (limit) is the most rows per page: 1 to 200, 100 by default. When more rows follow, the route answers with the header X-Next-Cursor, and the command prints the line that shows the next page:

More results: lakana runs list --env dev --status failed --limit 50 --cursor eyJrIjogInJ1bnMiLCAibyI6ICIyMDI2LTEwLTE4VDA5OjMwOjEyLjM0NTAwMCswMDowMCIsICJpIjogIjVjMGI3ZDRlLTJmMWEtNGI4ZS05ZDYzLTBhMWU3YzRmOWIyMSJ9

With --output json the line goes to stderr, so the JSON on stdout stays one list. The cursor is opaque: pass it back unchanged, with the same filters and the same limit.

A page continues strictly after the last row of the previous one. A run, query or deploy that arrives while you page is never shown twice, and none that was there is skipped. The one exception is a query that changes from queued to running between two pages, which moves to another part of the order of queries. The cursor belongs to its list: the cursor of the runs list is refused by the queries list, with 422 and a message that names both lists. Start again without cursor.

Refusals

Audit

A list of runs or deploys is not audited, and neither is a list of your own queries. When a manager's query list shows someone else's query, or filters on someone else with --submitter, the audit log gets one ACTIVITY_VIEWED event, and so does seeing the readers of a table (table health) and reading the audit log itself (lakana audit list) when the page shows someone else's events or filters on someone else with --principal-id:

The event never holds the names of the people seen, the ids of their queries or any SQL. The same person, view, environment or table and targeting key write one event per window: the next page, another status or event type, --all and a screen that refreshes itself add nothing. Looking only at your own queries or your own events, filtering on yourself, and a task's token record nothing. An instance administrator is recorded like anyone else.

If the event cannot be written, for example because the database is full, the list is refused with 503 and shows nothing; try again in a moment, and if it keeps failing ask the operator to check the server's database. Read the events with:

lakana audit list --event-type ACTIVITY_VIEWED

Other people's query text and column values in the audit log

Two fields of an event can hold content, which may be anything a table holds:

Reading the audit log needs READ_AUDIT_LOG; seeing these fields in someone else's events needs READ_QUERY_TEXT as well, which no role carries, ADMIN included. READ_QUERY_TEXT covers query text and column values in audit events, nothing else. Without it:

• Query text shows its SHA-256 and its length in characters, so that the same query can still be recognised across events. The hash is not a secret: someone who guesses the exact text can confirm the guess, which is easy for a short or common query.
• A watermark shows only {"hidden": true}: no hash and no length. Its values are numbers, dates and times, few enough to try them all against a hash, so a hash would give the value away.

"sql_text": {"sha256": "9f1c...e2", "length": 57}
"watermark": {"hidden": true}

Your own events always show in full. Holding READ_TABLE on the table does not show a watermark either: the right is about the audit log. A field of an event that the server does not know how to classify shows {"hidden": true} too. An administrator gives the right to a person with lakana grant create --kind INSTANCE --principal NAME --action READ_QUERY_TEXT; the grant and its revoke are in the audit log like every grant, and lakana access explain NAME lists it. It is given on the instance only.

How much text a new event stores is set on the server and every worker:

SDK and REST

The routes answer with a JSON list, as they did before they could be paged, and the cursor of the next page is in the X-Next-Cursor header (absent on the last page). list returns the rows of one page; list_page returns a page with items and next_cursor. The SDK takes a status or trigger as one word or a list of words, and since as a datetime with a time zone.

from datetime import UTC, datetime

import lakana

client = lakana.Client()
page = client.runs.list_page(
    "dev", status=["failed", "cancelled"], since=datetime(2026, 10, 18, tzinfo=UTC), limit=50
)
for run in page.items:
    print(run.id, run.status, run.job)
if page.next_cursor is not None:
    more = client.runs.list_page(
        "dev",
        status=["failed", "cancelled"],
        since=datetime(2026, 10, 18, tzinfo=UTC),
        limit=50,
        cursor=page.next_cursor,
    )