Stages is designed as a layered system, with each major component playing a specific role in how alarms are received, processed, and recorded. This separation is intentional and foundational to how the platform delivers reliability, consistency, and control at scale.
This article explains the three core components of Stages — web servers, the application layer, and the database — what each one is responsible for, and how they work together to support professional monitoring operations.
At a Glance
Stages is built around clearly defined system layers that separate access, decision-making, and data storage.
In simple terms:
- Web servers handle access for users and integrations
- The application layer controls all alarm behavior and system logic
- The database stores alarm data and history in a protected core
Each layer has a specific purpose, and no layer bypasses another. This structure helps Stages remain stable, predictable, and resilient over time.
Why Stages Uses Separate Core Components
In monitoring environments, reliability depends on more than just keeping systems online. It also depends on controlling how information moves through the platform and where decisions are made.
Stages separates its core components so that:
- Access does not equal control
- External systems cannot bypass logic
- Alarm behavior is consistent regardless of the source
- Data remains protected and auditable
By clearly defining the role of each component, Stages reduces operational risk and supports long-term scalability.
Web Servers: How Users and Systems Access Stages
Web servers are responsible for handling access to Stages. They serve as the entry point for people and systems interacting with the platform.
Stages uses multiple web servers to support different access needs, including:
- Internal access for dispatchers and supervisors
- External or remote access for authorized users
- Access for integrations and services that communicate with Stages
These web servers manage authentication, session handling, and request routing. Importantly, they do not make alarm decisions and do not store alarm data.
Their role is to provide reliable, controlled access while protecting the deeper layers of the system.
The Application Layer: Where Decisions Are Made
The application layer is the central control point of Stages.
This layer is responsible for:
- Interpreting incoming signals
- Applying system rules and configuration
- Classifying and prioritizing alarms
- Selecting and executing action plans
- Managing integrations with email, SMS, telephony, and other services
All alarm behavior flows through this layer. No users, integrations, or external systems interact directly with the database without passing through the application layer first.
This design ensures that:
- Alarm logic is applied consistently
- Configuration drives behavior
- Rules cannot be bypassed
- System decisions are traceable and repeatable
In practical terms, the application layer is where Stages “thinks.”
The Database: Where Alarm History Lives
The database layer stores the data that supports monitoring operations.
This includes:
- Alarm and event records
- Processing outcomes
- Operator actions and timestamps
- Dispatch and resolution details
- Historical data used for reporting and analysis
The database is intentionally protected and does not accept direct interaction from users or external systems. All data access is managed through the application layer.
This separation helps maintain data integrity, supports auditability, and reduces the risk of unintended changes to historical records.
How the Core Components Work Together
While each component has a distinct role, they are designed to work together as a coordinated system.
A simplified flow looks like this:
- A signal or request enters Stages through a web server
- The application layer processes the signal and applies the configuration
- Decisions and actions are determined by system rules
- Results and activity are recorded in the database
- Information is presented back to users through the web interface
By enforcing this flow, Stages ensures that alarms are handled intentionally and predictably, regardless of volume or complexity.
Why This Design Builds Trust
Separating web servers, application logic, and data storage is not about complexity — it’s about control.
This design:
- Prevents shortcuts that bypass rules
- Supports reliability during maintenance or system issues
- Enables consistent behavior under pressure
- Protects alarm history and operational records
- Allows the platform to evolve without disrupting operations
For customers, this means confidence that the system will behave as expected, even during peak events or unexpected conditions.
What This Means for Customers and Operators
For customers, these core components support:
- Stable system behavior
- Clear accountability
- Reliable historical data
- A platform designed for long-term use
For operators, it means:
- Alarms arrive already processed and prioritized
- Workflows remain consistent across shifts
- System behavior is predictable and reliable
The complexity required to support this structure exists behind the scenes, not in day-to-day alarm handling.
A Final Thought
Stages is not built as a single, monolithic system. It is built as a coordinated set of components, each with a clear responsibility.
This separation allows Stages to deliver reliability, consistency, and survivability — not through workarounds, but through design.
Where to Go Next
To continue learning about how Stages is designed, explore:
- How Stages Is Built: A Plain-Language Architecture Overview
- Why Stages Is Designed for Reliability and Survivability
- Stages System Architecture: A Technical Overview for Advanced Readers
- Key Concepts to Understand Before Using Stages