Query
Pulls historical events from the Retriever archive (your own S3 bucket) by pattern name, with optional JavaScript filters on field values. Queries are scoped to the matching pattern — only the relevant byte ranges of the S3 objects are fetched, not the whole archive. The bucket stays yours; Log10x never copies or re-ingests.
Example
"last 90 days of
payment_retryforacme-corp"412 events match the tenant filter, pulled directly from S3 in 1.8s. Sample:
More to ask
- "
ECONNREFUSEDcount by severity, last 24h" - "hourly buckets of
Payment_Gateway_Timeout, last week" - "all
Auth_Failedevents from Q1, raw"
Prerequisites
This tool requires the Retriever deployed. Set LOG10X_RETRIEVER_LOG_GROUP to enable the diagnostics line below the execution summary; without it, the response carries pollingError instead.
Tool schema (advanced)
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
from |
string | yes | — | Start of the query window. ISO8601, epoch millis, or relative (now-1h, now-24h, now-90d). |
to |
string | no | now |
End of the query window. Same grammar as from. |
target |
string | no | __SAVE_LOG10X_RETRIEVER_TARGET__ |
Target app/service prefix. Required if no env default is set. |
search |
string | no | — | Bloom-filter search expression: ==, \|\|, &&, includes(field, "substr"). Example: severity_level=="ERROR" && includes(text, "ECONNREFUSED"). |
filters |
string[] | no | — | JS filter expressions evaluated after Bloom-scoped fetch. AND-combined. Full TenX JS API. |
format |
string | no | events |
events (raw + metadata), count (totals + severity / service rollups), aggregated (time-bucketed series), ephemeral_series (Prometheus range-query shape). |
bucket_size |
string | no | 5m |
When format=aggregated or ephemeral_series. Examples: 1m, 5m, 1h, 1d. |
limit |
number | no | 500 |
Hard cap on events returned. 1–10000. |
environment |
string | no | — | Environment nickname (multi-env). |
Diagnostics line. When LOG10X_RETRIEVER_LOG_GROUP is set, the response appends a structured Diagnostics: line below the execution summary — scanned=826 matched=655 skippedSearch=142 streamRequests=36 streamObjects=120 workers=36/120 workerEvents=21751. On zero-result queries the response also includes a Why zero events: classification line that distinguishes Bloom miss, Bloom false-positive, stale indexer, and poll-timeout-truncated cases. When the env var is unset the diagnostics carry pollingError instead of failing silently. To check progress on a queryId without re-fetching from S3, use Status.