The demand model

Every guide mentions “the demand set” — this page pins down precisely how it is built, which actions change it, and how the numbers on the Demands page are computed.

Demands own dashboards and alerts

A demand is the aggregate root: every dashboard and every alert rule belongs to exactly one demand. That has two practical consequences:

• Cost rolls up. A demand’s stored-timeseries and cost estimates are the sum of its dashboards’ figures — the Demands page is a per-need ledger.
• Deletion cascades. Deleting a demand removes its dashboards and alert rules with it (the delete dialog lists them first).

What exactly is in the demand set

The demand set is the list of telemetry your agents forward — metric names, LogQL stream selectors, and trace service selectors, all covered by a single hash so agents apply one consistent version — and it is derived, never hand-maintained. For metrics:

demand set  =  metrics referenced by any dashboard panel query
            ∪  metrics referenced by any ACTIVE alert rule query

Metric names are extracted from the PromQL of every panel and rule. Two words in that definition do real work:

• Any dashboard — every dashboard’s latest saved version counts, whether or not anyone is viewing it.
• Active alert — paused rules don’t demand metrics. This includes freshly imported rules, which arrive paused until you attach a channel and resume them: until then, only the metrics their sibling dashboards use are collected.

Dashboards contribute the other signals too: the stream selectors of saved log panels and the service selectors of saved trace panels enter the same demand set — see Logs and Traces.

The set is recomputed in the background every few seconds and immediately on every mutation, then pushed to all connected agents over the control stream — changes take effect in near real time.

What changes collection, and what doesn’t

You do this	Effect on collection
Save a dashboard (new panel, changed query)	New metrics start forwarding within seconds
Delete a panel or dashboard	Its metrics stop, unless something else still uses them
Create or resume an alert rule	The rule’s metrics start forwarding
Pause an alert rule	Its metrics are released (unless used elsewhere)
Mute an alert rule	No change — muting only silences notifications; the rule keeps evaluating, so its metrics stay demanded
Import a demand	Dashboard metrics start; alert metrics wait until rules are resumed
Delete a demand	Everything it exclusively used stops

The union semantics matter: a metric used by three dashboards keeps flowing until the last consumer is gone. Nothing is double-collected, and nothing is dropped while somebody still needs it.

How the estimates are computed

The Stored Timeseries, Est. Cost/mo, and Est. Samples/mo columns come from a simple, transparent model:

• Stored timeseries counts the distinct timeseries in the metrics index (across agents) that match a demand’s — or dashboard’s — selectors. It is the same unit the Agents page counts, not a tally of metric names: one query can match many series.
• Samples/month assumes each stored series reports one sample every 15 seconds — about 175 thousand samples per series per month.
• Cost/month applies a flat per-series monthly rate to that count.

The estimates currently cover metrics only — demanded log streams and trace services do not yet appear in these columns.

These are estimates of what the demand asks for, not a bill — the Free Tier is not charged, and the columns exist so the cost–value link is visible while you design: add a panel, watch the number; remove one, watch it fall.

Portability

A demand round-trips as a single JSON bundle — demand + dashboards + alert rules — with IDs, provenance, and secrets stripped and channels referenced by name. Exports, file imports, and the integrations catalog all speak this one format. See Work with demands.

Next steps

• Demand-driven observability — why the model exists.
• Architecture — how agents enforce the set at the edge.
• Work with demands — the day-to-day workflow.