Limits
This page explains the usage and retention limits that apply to 1stLine by Burava.
Open Billing to review your organization’s current plan, accepted alert-event usage, event-pack credits, retention, and plan capabilities.
Billing is controlled in Burava Platform. 1stLine receives billing-control updates from Platform and uses them to apply accepted alert-event limits, retention, hard caps, and plan-based capabilities.
No per-responder cap
1stLine does not cap billing by the number of responders.
You can add the responders and escalation structure your organization needs. Usage limits are based on accepted alert events, retention, and plan capabilities.
Accepted alert-event usage
An accepted alert event is an alert event that 1stLine accepts for processing.
Accepted alert events are counted against the current billing period. Your plan can include a monthly amount of accepted alert events.
Accepted alert events include accepted firing and resolved alert occurrences. Repeated occurrences can count separately because they represent additional accepted alert activity.
1stLine uses a unique source event id for each accepted event so billing counts the same accepted event once.
Events that fail before acceptance do not count. Examples include invalid Schema Token authentication, missing organization context, or payloads that fail schema validation before 1stLine accepts the alert.
Event packs and remaining capacity
Some plans support event packs.
Event packs add accepted alert-event credits on top of your included monthly amount. Billing uses available event-pack credits before applying a hard cap.
Use event packs when you expect a short-term spike. If your organization regularly uses more than the included amount, change to a plan with a higher included alert-event volume.
Surge protection
Some paid plans include surge protection.
Surge protection is designed for real incidents, where alert volume can jump suddenly and temporarily. 1stLine bills by alert volume, but the product should not make an active incident harder by immediately punishing a noisy spike.
When surge protection applies, the sudden spike can be absorbed before the hard-cap decision is made. This keeps ingestion available for the incident spike while still preserving the accepted alert-event model for normal usage.
Surge protection is not meant for sustained usage above your plan. If your regular alert volume is consistently higher than your included amount, use Guide: Change Plan.
First overage grace
Some paid plans include first overage grace.
First overage grace applies when your paid plan first goes over its included accepted alert-event amount. Instead of immediately activating a hard cap, the first overage can be allowed so your team can keep receiving and handling alerts during the incident.
After that grace has been used for the plan, future overage without enough event-pack credits or surge protection can lead to a hard cap.
Hard cap behavior
When a hard cap is active, new schema ingestion can be disabled until the cap is cleared. This protects the organization from accepting more billable alert events than the current plan and credits allow.
Hard-cap evaluation happens after the available protections are considered:
- included accepted alert events
- available event-pack credits
- applicable surge protection
- applicable first overage grace
If the limit is reached and none of those protections can cover the overage, a hard cap can become active. In that state, new schema ingestion can be disabled, so new incoming alert events are not accepted for normal processing until the cap is cleared.
You can clear a hard cap by:
- changing to a plan with enough accepted alert-event capacity
- buying an event pack, when your billing setup supports event packs
- waiting for the next billing period, when the plan and billing state allow it
Retention
Retention is the number of days accepted alert history remains in normal 1stLine views.
Retention applies to alert data that has aged past the plan’s active retention window. The retention lifecycle moves older alert history out of live 1stLine views after the data becomes older than the current retention setting.
For example, if your plan has 90 days of retention, alert history older than 90 days is eligible to leave live views during retention processing.
Retention and downgrades
When you downgrade to a plan with a shorter retention window, the shorter retention window becomes the active limit for your organization.
After the downgrade is applied, older alert history that is outside the new retention window is eligible to be moved out of live views during the retention lifecycle. This may not happen at the exact moment you change plan, but you should treat the new retention window as the active limit once the plan is changed.
If you upgrade again, 1stLine can restore eligible archived alert history that is still within the new retention window and still available for restore. Archived copies are temporary. If you need to preserve history before or after a downgrade, contact support@burava.com before changing plan.
Default communication integration availability
Some plans include the system default communication integration, and some do not.
When your plan does not include it, Communication Rule routines that depend on it can show Plan disabled and pause until the plan includes that capability again.
See Communication for setup details.
AI Escalation availability
AI Escalation is plan-based.
When the current organization plan does not include AI Escalation, the AI Escalation pages can be view-only. You can review existing assignments and configuration, but you cannot create connections, edit rules, or start new assignments until the plan includes AI Escalation.
See Escalate to AI for the feature workflow.
Need help with limits?
Contact support@burava.com if you need help with accepted alert-event usage, retention planning, event packs, or a hard cap.