The query API is Loki-compatible, so your dashboards, alert rules and logcli habits carry over. What changes is that you are not running the storage behind it.

Do we have to give up structure to cut cost?

No. Attributes are kept, including the trace and span IDs. Volume is what you pay for, so the lever is dropping streams you never read rather than flattening the ones you do.

How long are logs kept?

Ninety days on Free and Scale, with custom retention up to a year on Enterprise. The free tier includes fifty gigabytes of log ingestion a month.

Can we alert on log content?

Yes. A LogQL expression can back an alert rule the same way a PromQL one can, so a pattern in the output is a first-class trigger.

Logs you canafford to keepin full.

Logs arrive from the OpenTelemetry Collector, Grafana Alloy or an SDK, and read back over a LogQL-compatible API. They sit in the same tenant as the trace that produced them, so a failing span and its output are one query apart.

Start free→Read the docs

insight / log managementLIVE

{service_name="payments-api"} |= "timeout"

ERRORupstream timeout after 3000ms trace_id=4f2c9a1b14:22:07.412

WARNretry 2/3 for charge_id=ch_881214:22:07.418

ERRORcircuit opened for psp.authorize14:22:07.902

INFOfallback queued, 41 pending14:22:08.110

Every line carries the trace ID, so the failing span and its output are one query apart.

What you get

Included on every plan, including the free tier.

LogQL-compatible query and label exploration, so existing Loki dashboards and alert rules keep working.

Structured attributes preserved instead of flattened, including the trace and span IDs.

Ninety-day retention on every plan, the free tier included, with fifty gigabytes a month free.

Log-based alert rules that fire on a pattern rather than on a metric someone remembered to export.

How it gets there

Three steps, then it is reporting.

01Send logs to the agent over OTLP, or scrape files with Alloy.

02The agent forwards them with the tenant header.

03Query them by label in Insights, or from Grafana.

What you can ask

What that looks like as a query.

LOGQL

{service_name="payments-api"} |= "timeout"

One service, one word, no index to plan.

LOGQL

{service_name=~".+"} | json | status >= 500

Structured fields filtered after parsing.

LOGQL

sum by (level) (count_over_time({service_name="checkout"}[5m]))

Error rate straight out of the log stream.

Related use cases

Application performanceTraces, service graph and the critical path →

Kubernetes monitoringPods, nodes, namespaces and workloads →

Infrastructure monitoringHosts, containers, databases and queues →

Questions

What teams ask about the log pipeline.

Something not here? Book thirty minutes with an engineer who works on the platform. Book a call →

Is this Loki?: The query API is Loki-compatible, so your dashboards, alert rules and logcli habits carry over. What changes is that you are not running the storage behind it.
Do we have to give up structure to cut cost?: No. Attributes are kept, including the trace and span IDs. Volume is what you pay for, so the lever is dropping streams you never read rather than flattening the ones you do.
How long are logs kept?: Ninety days on Free and Scale, with custom retention up to a year on Enterprise. The free tier includes fifty gigabytes of log ingestion a month.
Can we alert on log content?: Yes. A LogQL expression can back an alert rule the same way a PromQL one can, so a pattern in the output is a first-class trigger.

Start on the free tier.

20K active series, 50 GB of logs and 50 GB of traces a month, 90-day retention, and the whole of Insights.

Start free→Book a demo