Core Concepts
Essential terminology and concepts to understand before working with ATStatus.
Status Page
A Status Page is a public-facing webpage that displays the operational status of your services. It serves as a communication hub between your organization and your users, showing real-time availability, ongoing incidents, and planned maintenance.
ATStatus supports multiple status pages, each with its own:
- Unique URL (slug)
- Custom branding (logo, colors, theme)
- Set of components
- Incident history
- Settings and features
Components
A Component represents a service, system, or infrastructure element that you want to track and display on your status page. Each component has its own status indicator, uptime history, and can be monitored automatically.
Component Statuses
| Status | Indicator | Description |
|---|---|---|
OPERATIONAL | Green | Service is working normally |
DEGRADED | Yellow | Service is experiencing degraded performance |
PARTIAL_OUTAGE | Orange | Service is partially unavailable |
MAJOR_OUTAGE | Red | Service is completely unavailable |
MAINTENANCE | Blue | Service is under scheduled maintenance |
Component Groups
Components can be organized into groups for better organization. Groups:
- Can be collapsed/expanded on the status page
- Support nested hierarchies (parent/child groups)
- Show aggregate status based on child components
- Can be reordered via drag-and-drop
Incidents
An Incident represents a service disruption or issue that affects one or more components. Incidents are tracked with a timeline of updates, allowing you to communicate progress to users as you work to resolve the issue.
Incident Lifecycle
Created (Investigating)
│
▼
Identified ────► Monitoring ────► Resolved
│
▼
(Optional: RCA)Impact Levels
| Level | Description | Example |
|---|---|---|
MAJOR | Critical outage affecting most users | Complete service unavailability |
PARTIAL | Significant issue affecting some users | Feature unavailable for subset of users |
DEGRADED | Performance issues, service slower than normal | Increased latency, timeouts |
MINOR | Small issue, minimal impact | UI bug, minor feature issue |
Maintenance
Maintenance windows are planned periods of downtime or reduced service. Unlike incidents (which are unexpected), maintenance is scheduled in advance to notify users before it begins.
Maintenance States
| State | Description |
|---|---|
SCHEDULED | Maintenance is planned but hasn't started yet |
IN_PROGRESS | Maintenance is currently active |
COMPLETED | Maintenance has finished |
Monitoring
ATStatus can automatically check your services at regular intervals to detect outages. When a monitor detects an issue, it can automatically update the component status and optionally create an incident.
ATStatus supports 25 monitor types, including:
- Network: HTTP/HTTPS, TCP, UDP, ICMP (ping), WebSocket, gRPC
- DNS: A, AAAA, MX, CNAME, TXT, NS record checks
- Databases: MySQL, PostgreSQL, MongoDB, Redis, Elasticsearch
- Message Queues: RabbitMQ, Kafka
- Infrastructure: Docker, Kubernetes, S3/MinIO
- Advanced: JSON API, GraphQL, SMTP, IMAP, custom scripts
Users & Roles
ATStatus supports multiple admin users with role-based access control (RBAC). Each user is assigned a role that determines what they can see and do.
Default Roles
| Role | Level | Capabilities |
|---|---|---|
OWNER | 100 | Full access to everything, manage all users, cannot be deleted |
ADMIN | 50 | Manage status page, incidents, components, limited user management |
MEMBER | 20 | Create/update incidents and maintenance, view dashboard |
READ_ONLY | 10 | View only, no modifications allowed |
Notifications
ATStatus can notify users and teams when events occur. Notifications can be sent through multiple channels based on configurable event triggers.
Notification Channels
- Discord Webhooks — Rich embeds with customizable appearance
- Email (SMTP) — Direct email notifications
- Custom Webhooks — HTTP POST to any endpoint
- Push Notifications — Browser push via service workers
- Subscribers — Email list for public users
Event Types
- Incident created / updated / resolved
- Maintenance scheduled / started / completed
- Component status changed
- Component created / deleted
- Uptime alerts (threshold breached)
- Scheduled reports (daily/weekly/monthly)
Audit Logging
Every administrative action is logged in a tamper-proof audit trail. The audit log uses a hash chain to ensure integrity — any modification to past entries would be immediately detectable.
The audit log captures:
- Who performed the action (actor)
- What was changed (entity, field, old/new values)
- When it happened (timestamp)
- From where (IP address, user agent)
- Event severity level
- Cryptographic hash chain for tamper evidence
The hash-chained audit trail meets the requirements for ISO 27001, SOC 2, and GDPR audit logging standards.