Monitoring types
5
Website, API, SSL, Ping, TCP
Product Overview
Alertum Platform Deep Dive
Alertum is built as a connected reliability system, not isolated feature pages. Monitoring creates signal, incidents organize context, escalation routes ownership, and status communication closes the loop externally. This page outlines the core modules and what each one contributes operationally.
Incident severities
4
Critical, High, Medium, Low
Incident states
4
Open, Acknowledged, Resolved, Reopened
Analytics windows
5
1h, 24h, 7d, 30d, 365d
Native integrations
10
Chat, webhook, and API channels
Plans
4
Free, Solo, Team, Business
Module Breakdown
What Each Area Owns
Monitors
Track website availability, API health, SSL expiration, ICMP reachability, and TCP port availability.
- Status code, response-time, and payload assertions
- Flexible check intervals and failure/recovery thresholds
- Uptime history and latency visibility in one view
Expected Outcomes
Faster outage detection
Consistent endpoint health baselines
Incidents
Detect, classify, and resolve incidents from monitoring failures, integrations, and journey errors.
- Severity levels and assignment workflows
- Automatic and manual grouping support
- Comments, status transitions, and incident timelines
Expected Outcomes
Lower alert noise
Clear ownership during incidents
Heartbeats
Confirm cron jobs, workers, and scheduled tasks by expecting pings within interval + grace windows.
- Missed heartbeat detection
- Dedicated ping endpoint per heartbeat
- Operational view for background reliability
Expected Outcomes
Early job-failure visibility
Reduced silent data pipeline failures
Synthetic Journeys
Run multi-step synthetic flows to validate end-to-end user journeys, not only single endpoints.
- HTTP, assert, and wait steps
- Frequency and max-duration controls
- Run history with failed-step diagnostics
Expected Outcomes
Business-flow verification
Root-cause clues for user-impacting issues
Status Pages
Publish service health externally with dedicated status pages linked to selected monitors.
- Public and private visibility modes
- Monitor and incident communication surface
- Per-page monitor selection and publication controls
Expected Outcomes
Higher customer trust
Lower inbound support load
Maintenance Windows
Schedule planned downtime, set clear windows, and communicate expected impact in advance.
- Upcoming, active, and completed state handling
- Duration-aware maintenance timeline
- Operational clarity during planned changes
Expected Outcomes
Predictable change windows
Reduced false-positive incident noise
On-Call Scheduling
Manage rotation schedules and maintain 24/7 ownership for incident response.
- Current and next on-call visibility
- Weekly timeline and rotation forecasting
- Escalation-ready schedule targets
Expected Outcomes
Always-defined responders
Stronger escalation reliability
Escalation Policies
Define structured, multi-level routing with timed delays and channel-based notification steps.
- Targets: users and on-call schedules
- Channels include Email, Slack, PagerDuty, Webhook, SMS, and phone call
- Scope by monitor, heartbeat, and synthetic journey
Expected Outcomes
Less manual paging
Consistent incident response paths
Integrations + Error Intake
Connect Alertum to chat tools, webhooks, APIs, and ingest app errors directly as incidents.
- Team API key based ingestion endpoint
- Payload context: project, service, environment, group
- Unified catalog and per-integration enable/disable control
Expected Outcomes
Unified alert distribution
Faster triage from app-level events
Next Step
Map Platform Features to Your Response Process
After understanding module scope, the next step is seeing how these capabilities work together during real incidents and planned operational workflows.