Work with demands

A demand is LeanSignal’s unit of intent: a named need that owns dashboards and alert rules, and through them declares which metrics your agents forward. The Demands page is where the cost–value link becomes concrete — every demand shows what it consumes and what that is estimated to cost.

The page has three tabs:

• Demands — the demand list itself, described below.
• Filters — the materialized demand set: every selector currently in force across all demands (metric, log, and trace rules extracted from dashboards, alerts, and ingestion rules), each with a live count of what it stores and a one-click jump to query it.
• Purge — the audit trail of removed selectors and the Collect garbage action — see Purge.

Three ways to create one

• Import from the catalog — the fastest path. Press the ˅ arrow on the Add Demand button and choose Import from catalog…; pick an integration and variant, and you get a demand with curated dashboards and alerts in one step. If the catalog is unreachable, enter the variant’s demand slug directly.
• Import from file… — the same menu imports a previously exported bundle. You get a dry-run preview first: dashboard and alert counts, a check of which referenced notification channels exist in your tenant, and the note that a new demand is created — nothing existing is overwritten.
• Add Demand — the button itself (not its ˅ arrow) starts an empty demand with a Name and optional Description; attach dashboards and alerts to it as you build.

What a demand shows you

The list is the cost–value ledger of your tenant:

Column	Meaning
Stored Timeseries	The timeseries stored centrally because they match this demand’s filters — the same unit the Agents page counts. Counted over the full 30-day retention window, so it includes demanded series that have since gone quiet (retired pods and other churn) — stored being larger than currently-active is expected.
Est. Cost/mo	Estimated monthly cost of collecting this demand’s metrics (hidden by default; does not apply in the Free Tier).
Est. Samples/mo	Estimated monthly sample volume (hidden by default).
Owner	Who created it.

Estimates are computed continuously from the demand’s deduplicated set of timeseries, assuming one sample every 15 seconds per timeseries — so they move the moment you add or remove a panel or alert. Retire a dashboard and you can watch its cost leave the ledger.

Click a demand’s name to see everything under it: its dashboards (linked) and its alert rules.

Export and portability

Every demand can be exported as a single JSON bundle — the Download action in its row saves <name>-<date>.json containing the demand, its dashboards (full Perses specs), and its alert rules. Two properties make bundles safe to share:

• No secrets. Server-owned record fields (IDs, provenance, timestamps, cost stats, alert runtime state) are stripped; notification channels are referenced by name only — never by ID or webhook secret. The bundle keeps only an informational source-tenant and export-time stamp as provenance.
• Import is additive. Importing a bundle always creates a fresh demand owned by you; channels are matched by name, and any alert whose channels don’t match arrives unlinked and paused.

This is the same format the integrations catalog publishes — your exports are first-class bundles, useful for promoting a demand between tenants or keeping it in version control.

Deleting a demand

A demand is the aggregate root: deleting it permanently removes everything under it. The delete dialog lists exactly which dashboards and alerts will go with it before you confirm. The demand set recomputes automatically, so any metrics nothing else consumes stop being forwarded — deletion genuinely ends the cost, and the stored data the demand justified is purged after a grace window (see Purge).

When deleting a demand, dashboard, or alert would remove the last reference to a selector, the dialog offers to keep the collected data: the selector is preserved as a disabled ingestion rule, which protects its stored metrics and logs from purge while collecting nothing new. Stored traces are the exception — span storage is per-rule, so the old rule’s spans are purged either way (see Traces).

Purge: what happens to stored data

Central storage only ever holds what a demand asks for — so when demand goes away, the data it justified goes too. Two mechanisms enforce this:

• Automatic purge on removal. Whenever a selector leaves the demand set — a panel deleted, an alert removed, an ingestion rule or a whole demand deleted — the removal is recorded, and after a grace window (24 hours by default; admins can change it under Settings → Data Retention) the stored series and streams that no surviving selector still matches are deleted from central storage. Anything a surviving selector covers is kept — overlap protects data, so removing one of two dashboards that share a metric deletes nothing.
• Collect garbage. The Purge tab’s Collect garbage button (editors and admins) runs an on-demand mark-and-sweep over everything in central storage: it keeps whatever any demand still matches — plus the platform’s own consumption series — and permanently deletes the rest. Use it to clean up leftovers the automatic path can’t see — strays whose removal was never recorded, or data predating the purge machinery. The panel above the table narrates the run’s progress per store, and a safety guard aborts a sweep that would delete an implausibly large share of a store.

The Purge tab’s history table is the audit trail: every removed selector, when it left the demand set, and its outcome — pending (inside the grace window), purged (deleted, with the series/stream count), kept (a surviving selector still matches the data, so nothing was deleted), or failed (the delete errored and will be retried). Click a row to see the full record plus a live check of how much stored data still matches that selector right now — the expected answer is none.

Demanded data is never deleted

Purging is driven only by demand — never by activity. If any live selector matches a stored series, stream, or span, it is kept no matter how long ago it last received data: quiet history under a live selector (retired pods, finished jobs) is legitimate stored data and leaves only through the 30-day retention. The way to delete data early is to delete the demand for it.

Next steps

• Build dashboards — dashboards express demand automatically.
• Alerting — alert rules do too.
• Demand-driven observability — the model behind the ledger.