Plans and limits

Every plan gets heartbeat monitoring and fixed-threshold numeric rules. Plans differ in how much you can use: how many monitors, how often they beat, how many measurements each beat carries, and how much history you keep.

Plans at a glance

Plan	Monitors	Fastest interval	Measurements per beat	History: raw / 5-minute / hourly	Callback endpoints	API requests/min	MCP requests/min
Free	1	5 min	2	7 days / none / none	1	60	30
Builder	25	1 min	8	30 days / 90 days / 365 days	5	300	120
Smart	100	1 min	16	30 days / 90 days / 365 days	20	1,200	600
Scale	500	1 min	16	30 days / 90 days / 365 days	50	6,000	3,000

Free is one complete monitor with a week of raw history. A second service needs a paid plan.

What each limit means

• Monitors: how many active monitors you can have. At the limit, creating another is refused. Delete or archive one to free its slot, or upgrade.
• Fastest interval: how often a monitor’s beats are accepted. It isn’t a default cadence. A monitor keeps the cadence you set or the one it measures. If that cadence is shorter than your plan allows, the monitor is watched at the plan’s interval. See Publish.
• Measurements per beat: the most numeric values one beat can carry.
• History: how long you can see every individual beat (raw), then five-minute and hourly summaries. “None” means that summary isn’t kept.
• Callback endpoints: how many callback destinations you can configure.
• API and MCP requests/min: how many requests you can make in one UTC minute, counted separately for the REST API and MCP.

A request over a limit gets signalsitter.rate_limited. REST problems include a limit object naming the limit, your plan, current and attempted usage, and what to do. See REST.

Check your plan and current usage with Get entitlements or the signalsitter_get_entitlements MCP tool.

Note

The entitlements response still lists older learned-detection features for compatibility. Production presents heartbeats and fixed-threshold rules only.

History

• Raw: every beat exactly as you sent it.
• Five-minute: after the raw window, beats are summarized into five-minute buckets.
• Hourly: after that, hourly buckets.

How long each is kept depends on your plan; see the table above.

A bucket keeps counts, value summaries, statuses, and whether a beat in it contributed to an incident. It doesn’t keep the individual beats.

History reads and exports return raw beats only by default. Add includeObservationBuckets=true to get buckets too. Each bucket has a resolutionSeconds of 300 or 3600.

Changing plans

Only an organization owner can start a checkout or open the billing portal, in the dashboard. API credentials and MCP clients can’t. Any credential with usage:read can read billing state, so an agent can explain why a plan changed.

Downgrades

• Your history stays readable.
• If you have more monitors than the new plan allows, the oldest are kept, by creation time. The rest are suspended.
• Usage above any other new limit is reported as over the limit. Creating new resources is refused until you reduce it.
• List allotment transitions shows which monitors were suspended or released, and why.

A suspended monitor:

• refuses beats with signalsitter.rate_limited and the limit active_monitors;
• keeps every observation it already recorded;
• raises no incident while suspended;
• resumes on its own when you upgrade or delete or archive another monitor.

Restoring an archived monitor needs a free slot. Without one, the restore is refused rather than suspending another monitor.

Payment grace

• A failed payment holds your plan in payment grace until the payment provider stops retrying.
• Billing state shows the end of grace as graceEndsAt, taken from the provider’s own schedule. Your plan continues until then.
• A chargeback opens the same grace window instead of suspending service. If the cardholder wins, your organization moves to Free. If the chargeback is decided in our favour, your plan continues.

Ending a subscription

• Your organization moves to Free. Monitoring keeps running under Free’s limits. Nothing goes read-only.
• Preview cancellation first. It shows which monitors Free keeps and what narrows on each.
• Free holds one monitor. In the preview, every monitor but your oldest is listed as suspended_over_allotment. Those stop accepting beats when the cancellation lands.
• Nothing is deleted. Suspended monitors keep their history, stay readable and exportable, and raise no incidents.
• They resume on their own when you upgrade, or when you delete or archive the monitor holding the slot.