Query Jobs

Query Jobs let you run long-window log searches asynchronously, save the results, and come back later to filter, analyze, or export them. They are the right tool when a search is too broad or too long-running for the interactive Log Explorer — for example, scanning the last 30 days of error logs across all clusters, or pulling the full body of every request from a specific workload over a week.

A Query Job runs in the background. You don't need to keep the browser open. Once it finishes, the results are persisted as a saved artifact for as long as the job's TTL allows — re-query, export, or share the link with a teammate without re-running the original search.

Where to Find Query Jobs

The Query Jobs entry lives in the left sidebar under the Logs section, between Archived Logs and Log Pipelines.

The page has two views:

List page — every saved job, with a state pill (Running, Completed, Failed, Canceled), the job title, who created it, result row count, and expiry.
Job detail page — the status banner, the results table, a re-query bar, and actions like Extend TTL, Export, and Delete.

Creating a Job

Click New Query Job on the list page to open the creation modal. Pick one of two query types:

SPL

For pipeline-style searches with fields, filter, stats, sort, etc. — the same SPL syntax described in Search Processing Language. Paste or type your SPL query into the editor:

fields timestamp, body, workload, level
| filter level = "ERROR"

SPL jobs accept any valid SPL pipeline. If you don't include a | limit N clause, the entire matched result set is materialized (subject to your platform's row cap).

Advanced Query

For users who prefer the same Advanced Query syntax used in the Log Explorer (e.g. level = "ERROR" AND workload = "checkoutservice"). The same query-builder editor is embedded in the modal — autocomplete and field suggestions work the same way.

Common Fields

Every job, regardless of type, also takes:

Title — a short label so the job is easy to identify later in the list. Required.
Time Range — the from/to window the query runs against.
TTL — how long the saved result lives before it is automatically cleaned up. Default is 7 days. Range: 60 seconds to 30 days.
Max Attempts — how many times KubeSense may rerun the job if the worker process restarts mid-execution. Default is 1.

Clusters are taken from the global topnav selector — the modal does not ask for them again.

Click Run to submit. The modal closes and the job appears in the list immediately in Queued state.

Job States

Each job moves through a lifecycle. The state pill on the list and the banner on the detail page reflect the current step:

Queued — accepted, waiting for a worker.
Running — actively materializing results in ClickHouse.
Finalizing — results written, finishing up.
Completed — results are ready to read, filter, and export.
Failed — the query errored. The banner shows the failure reason.
Canceled — a user clicked Cancel before completion.

The list polls every few seconds while any job is active, so you can leave the page open and watch progress.

The Detail Page

Open a job from the list to see its detail page. The top of the page is a state-themed status banner showing:

Result Rows (for completed/running jobs) or Failure Reason (for failed jobs) or Canceled (for canceled jobs).
The job's type chip (SPL / Logs), state chip, and any state-specific action button (Cancel / Retry).
A kebab menu (⋮) on the right with secondary actions — Extend TTL, Export, Delete.

Below the banner sits the re-query bar and the results table.

Cancel

While a job is Queued, Running, or Finalizing, the banner shows a Cancel button. Clicking it stops the in-flight query. The job moves to the Canceled state and any partial results are discarded.

Retry

For Failed or Canceled jobs, the banner shows a Retry button. Clicking it re-runs the original query from scratch with a fresh attempt budget. The job ID stays the same — useful when you want the same SID for sharing or bookmarks.

Extend TTL

A job's results are deleted when its TTL expires. To keep them longer, click Extend TTL in the kebab menu. Pick a new TTL value and unit (seconds / minutes / hours / days). The new expiry is set to now + your value — TTL can be extended further, never shortened.

Delete

Permanent. Removes the job row and drops the saved result table from ClickHouse. A confirmation dialog protects against accidental clicks.

Re-Querying Saved Results

Once a job is Completed, the re-query bar above the results table lets you filter, sort, or paginate the saved artifact without re-running the original search. Two modes:

Advanced

For jobs created with the Advanced Query type, use the same AND / OR / IN expressions you'd write in the Log Explorer. Type into the bar and click Run — the table re-renders with the filtered subset, and the Result Rows badge updates to show the filtered count of the total.

level = "ERROR" AND workload = "checkoutservice"

SPL

Available for both Advanced and SPL job types. Write any SPL pipeline against the saved result table:

fields workload, level
| stats count(*) as errors by workload
| sort errors desc

The bar's Reset button clears the filter and restores the unfiltered result list. The Export button on the bar exports just the filtered subset.

Note: SPL jobs only accept SPL re-queries. Advanced jobs accept both SPL and Advanced re-queries.

Exporting Results

You can export job results as CSV or JSON. Two paths into the export dialog:

Kebab → Export — opens the dialog with no filter applied; exports the full saved result.
Re-query bar → Export — opens the dialog with the current re-query filter pre-applied. A checkbox in the dialog lets you toggle the filter off.

In the dialog:

File type — CSV or JSON.
Max rows — 10,000 / 50,000 / 100,000. This is the hard cap on the export, regardless of how many rows the result actually has.

Click Download to start. The browser saves the file directly — large exports may take several seconds to assemble before the download begins.

Reading the Results Table

The results table renders whatever columns your job's query projected. The toolbar above the table has two helpful toggles:

Single-line / Wrap-lines — switch between truncated cells (with hover-to-see-full) and full multi-line cells. Wrap is useful when reading body text or stack traces.
Column toggler — show / hide individual columns. Hidden columns can always be brought back from this menu.

Pagination sits at the bottom right. Each page shows 100 rows; the badge shows the total result count.

The List Page

Jobs are listed newest first. A row shows the title, type, state, result count, attempts, created-by, created-at, completed-at, and expiry-from-now.

State filter pills along the top — All, Running, Completed, Failed, Canceled — narrow the list to the selected lifecycle state.
Pagination at the bottom right — 50 jobs per page.
Row click — opens the job's detail page.
Row kebab (⋮) — Open, Delete.

The list refreshes automatically every few seconds while any job on the page is active, and every minute otherwise.

Permissions

Query Jobs are gated behind the Logs RBAC module. Any user with access to the Logs module can create, view, re-query, and export their own jobs. Owners (the user who created the job) can also cancel, retry, extend TTL, and delete it. Non-owners see the job in read-only mode.

The query the worker runs uses the owner's RBAC filters snapshotted at creation time — so a job sharing a result with someone whose access scope is narrower still only returns rows the owner could have seen at creation time.

When to Use Query Jobs vs. Log Explorer

Use the Log Explorer for interactive search over the last few hours / days — quick filtering, ad-hoc SPL, live tailing.

Use Query Jobs when:

The time range is too large for an interactive search (multi-day / multi-week).
You want the result to outlive the browser session.
You want to export a large result (tens of thousands of rows) for offline analysis.
You want to re-filter the same baseline result multiple times without re-scanning the source logs every time.

Query Jobs

ON THIS PAGE