Overview
The Virtual Facility (VF) platform continuously processes alarm traffic from client facilities. During periods of unusually high alarm volume, the system automatically applies high alarm load throttling controls to protect platform stability and ensure alarm processing continues for all clients.
What Is a High Alarm Load?
A high alarm load occurs when a client generates alarm traffic at a volume high enough to risk overwhelming the processing pipeline. This can result from sudden spikes, sustained high volumes, or malfunctioning integrations generating excessive alarms.
What Triggers Deferred Alarm Processing?
The platform uses two independent metrics to determine when alarm traffic should be routed to deferred processing.
1. Rolling Alarm Volume Threshold
Deferred processing is triggered when more than 100,000 alarms are received for a single client within a rolling 60‑minute window. Alarm volume is combined across all integrations belonging to that client.
2. Single-Batch Threshold
Deferred processing is also triggered when a single API request contains 10,000 or more alarms. This serves as a backstop against sudden spikes.
What Happens When Alarms Are Deferred?
Deferred alarms are not blocked or discarded. The system routes them to a separate processing lane designed to protect shared platform capacity. The live processing lane is 10x more robust than the deferred processing lane.
This creates an intentional throttling effect of approximately 10x while still guaranteeing eventual processing.
How Long Does Deferral Last?
There is no fixed delay window. A client remains deferred for as long as their rolling 60‑minute alarm volume exceeds 100,000 alarms. Once the volume ages out of the rolling window and falls below the threshold, processing automatically returns to normal. Oversized single-batch events typically affect only that batch unless additional threshold conditions continue to be met.
Expected Processing Delays
Processing time depends entirely on backlog size and current platform load. Small spikes may clear quickly, while sustained alarm floods may take significantly longer to drain through the deferred queue.
Deferred Processing Alerts
Currently, there is no client-facing alert mechanism to warn users when there is a high alarm load and deferred processing occurring. However, in Q3 2026 we will be releasing email notifications for alarm processing deferrals. These emails will be similar to the existing system status alerts.
There is a 60‑minute alert cooldown controls how frequently operators are alerted. It does not determine how long a client remains deferred.
Conclusion
A client enters deferred processing when either more than 100k alarms are received within a rolling 60‑minute window or a single API request contains 10k+ alarms. Deferred alarms are processed through a throttled queue and are not lost.