Signals is a usage dimension alongside workspaces, memories and rules. The public unit is **Signals processed per month**, measured on a UTC calendar-month boundary (`00:00 UTC` on the first day) regardless of whether you bill monthly or yearly.

## Monthly limits

| Plan | Signals / month | Monitored workspaces |
|---|---:|---|
| **Solo** | 1,500 | 1 |
| **Team** | 100,000 | Unlimited, one shared quota |
| **Business** | 500,000 | Unlimited, one shared quota |
| **Enterprise** | Custom | Custom |

- **Solo** is a real but deliberately bounded one-project experience: Signals runs in a single monitored workspace. Your other workspaces keep every non-Signals feature.
- **Team** and **Business** share one organization-wide Signals quota across as many monitored workspaces as you like. Business has five times Team's capacity.
- **Enterprise** uses a contract value; platform-wide abuse guards still apply.

## What counts

- A valid error or event occurrence accepted for processing counts **once**.
- A coalesced batch carries a delta; the accepted delta consumes the allowance even though it is one network request and one row update.
- **Declarations, connection announcements, quota checks, rejected malformed payloads, and release-coverage touches do not count.**
- Traffic suppressed beyond a per-fingerprint daily spike ceiling does not count.
- A batch that crosses the monthly boundary is partially accepted up to the remaining allowance.

There is no grace period past 100%. When the quota is exhausted, **Signals ingestion pauses for the rest of the period**, and nothing else does. Memories, rules, workspaces, and Tasks stay fully writable. The next period resumes automatically.

## Usage and warnings

Your usage is shown like any other dimension:

```text
Signals this period    842 / 1,500
Resets                 Aug 1
Monitored workspaces   1 / 1
```

- At **80%**, a neutral usage warning.
- At **90%**, a strong warning with an upgrade action.
- At **100%**, new Signals are paused until reset; every other capability is unaffected.

Studio also breaks down accepted, spike-suppressed, quota-suppressed, and cardinality-suppressed counts, so you can always see why something did not land.

## Guardrails

Beyond the monthly quota, a few internal guards keep one runaway product from swamping your allowance or the platform:

- **Spike ceiling.** A per-fingerprint daily cap stops a single runaway error from consuming the whole organization allowance; suppressed volume does not count.
- **Hot-group cap.** A limit on concurrently active grouped identities stops a flood of unique fingerprints. Existing groups keep updating; new ones are suppressed and surfaced in Studio rather than failing silently.
- **Rate limit.** A per-key request-rate ceiling, independent of monthly volume.

## Retention

Signals keeps only what is useful and compacts the rest on a bounded schedule:

| Data | Kept until |
|---|---|
| Unlinked production incident, unseen | 14 days, then deleted |
| Unlinked development / preview incident, unseen | 7 days, then deleted |
| Stale declaration, unseen | 30 days, then deleted |
| Verified incident | Shown as proof for 30 days |
| Verified / card-linked incident | Cold-compacted 90 days after last evidence |
| Cold tombstone with no recurrence | Purged after 12 months |

Cold compaction clears the heavy fields (message, stack, context receipt, detailed evidence) but keeps the small identity needed to prevent a duplicate task. A recurrence before the tombstone expires rehydrates the **same** incident and reuses the **same** card, it never creates a duplicate.

## What to read next

- [Signals overview](/docs/signals/overview) for the product story.
- [Setting up Signals](/docs/signals/setup) to turn it on in Pathrule Studio.