The Alert24 Hierarchy
Alert24 organizes your monitoring and incident management into a clear hierarchy. Understanding this structure makes it easy to set up and maintain your monitoring as your infrastructure grows.
Organization
├── Applications
│ └── Services
│ └── Monitoring Checks
├── Status Pages
│ └── Services (displayed on the page)
└── Incidents
└── Updates
Organizations
An organization is your team's top-level workspace. Everything else — services, monitoring, status pages, incidents, and team members — belongs to an organization.
Most teams have one organization. Agencies or MSPs managing multiple clients might create separate organizations for each client.
Applications
An application groups related services together. Think of it as a logical container that represents a product or system.
Examples:
- "Customer Portal" — containing your web app, API, and database services
- "Payment System" — containing your payment API, Stripe integration, and webhook processor
- "Marketing Site" — containing your website and CDN services
Applications help you answer the question: "If this service goes down, what's affected?"
Services
A service is an individual component of your infrastructure that you want to track. Services are the core building block in Alert24.
Examples:
- Production API
- PostgreSQL Database
- Cloudflare CDN
- SendGrid Email Delivery
Each service has a status (operational, degraded, partial outage, major outage, or maintenance) that can be updated manually or automatically based on monitoring checks.
Services can belong to one or more applications and appear on one or more status pages.
Monitoring Checks
A monitoring check is an automated test that runs on a schedule to verify a service is working. Alert24 supports two types:
HTTP Checks
Send HTTP requests to your endpoints and verify the response. You can check status codes, look for keywords in the response body, verify SSL certificates, and measure response time.
Status Page Checks
Monitor third-party provider status pages (like AWS, Cloudflare, or Google Cloud). Alert24 reads the provider's status page feed and detects when they report incidents that affect services you depend on.
Each check is linked to a service. When a check detects a problem, it can automatically update the linked service's status.
Status Pages
A status page is a public-facing webpage that shows the current health of your services. Your customers visit this page to check if everything is working or to get updates during an incident.
Status pages display:
- Current status of each listed service
- Active incidents and their updates
- Scheduled maintenance windows
- Historical uptime data
You can customize status pages with your branding, logo, and colors. You can also use a custom domain.
Incidents
An incident represents an event where one or more services are experiencing problems. Incidents have:
- Severity level — How bad is it? (minor, major, critical)
- Status — Investigating, identified, monitoring, resolved
- Updates — Timestamped messages posted as the incident progresses
- Affected services — Which services are impacted
Incidents appear on your status pages automatically, keeping your customers informed without manual effort.
How They Connect
Here is how all these concepts work together in practice:
- You create services representing your infrastructure components
- You attach monitoring checks to those services to detect problems automatically
- You group services into applications to understand dependencies
- You build status pages to show service health to your customers
- When a problem occurs, you create an incident, post updates, and resolve it when fixed
This structure scales from a simple setup with a single service and status page to complex environments with dozens of services across multiple applications and status pages.