Proposal: Independent Status Pages and Health Checks

[Artesfrost]

Summary

It would be useful to add Status Pages as an independent entity in IncidentRelay.

The idea would be to allow users to create a Status Page, define its components, configure how each component is checked, and display the current health of those components.

The initial implementation would not necessarily need to depend on Alerts, Incidents or the Incident Management workflow.

Instead, a Status Page could work independently and later integrate with other IncidentRelay entities where useful.

Basic Concept

For example, a user could create:

Status Page: Production Services

Components:

Web Application       Operational
API                   Operational
Authentication        Degraded
Database              Operational
External API          Operational

Each component could have its own health-check configuration.

The Status Page would periodically execute those checks and calculate the current component state.

Status Page Configuration

A Status Page could contain:

• Name
• Description
• Components
• Refresh/check interval
• Public / Private visibility
• Optional authentication
• Status history

Each component could contain:

• Name
• Description
• Check type
• Check configuration
• Current status
• Check interval
• Timeout
• Failure threshold
• Recovery threshold

Possible states could include:

Operational
Degraded
Partial Outage
Major Outage
Maintenance
Unknown

Health Checks

The first version could support a small number of useful checks.

HTTP / HTTPS

For example:

URL: https://service.example/api/health
Method: GET
Expected HTTP Status: 200
Timeout: 5s

Additional options could include:

• Headers
• Basic Authentication
• Bearer Token
• Expected response body
• Response body matcher
• JSON field/value matcher
• Response-time threshold

For example:

GET https://service.example/api/health

Expected:

HTTP 200

AND

response.status == "UP"

AND

response time < 2000 ms

TCP

For services without an HTTP health endpoint:

Host: database.example
Port: 5432
Timeout: 5s

ICMP / Ping

A simple host availability check could also be useful.

Component Status

The result of the configured checks would determine the component status.

For example:

Authentication

HTTP 200
response.status = UP
response time = 320 ms

→ Operational

or:

Authentication

HTTP 200
response.status = UP
response time = 4200 ms

→ Degraded

or:

Authentication

HTTP timeout

→ Major Outage

Failure and recovery thresholds could prevent a single temporary failure from immediately changing the public status.

For example:

Failure threshold: 3 checks
Recovery threshold: 2 checks

Independent Entity

An important part of the proposal is that the Status Page could initially work independently from Incident Management.

For example:

Status Page
    ↓
Components
    ↓
Health Checks
    ↓
Component Status
    ↓
Status History

This would allow IncidentRelay to provide a simple service-health view without requiring an Incident to exist.

Future Integrations

Later, Status Pages could optionally integrate with other IncidentRelay entities.

Possible examples:

Heartbeat → Status Component
Service → Status Component
Maintenance → Status Component
Alert → Status Component
Incident → Status Component

For example, an existing Heartbeat could potentially be selected as the health source for a component instead of creating another check.

Maintenance could automatically display:

Authentication
Scheduled Maintenance

And an Incident could optionally be published to a Status Page when communication about an outage is required.

However, these integrations would be optional extensions rather than requirements for the initial Status Page implementation.

Internal and Public Status Pages

It could also be useful to support different visibility modes.

For example:

Internal Status Page

Infrastructure
Database
Monitoring
Internal APIs
Authentication

and:

Public Status Page

Web Application
Mobile Application
API
Payments
Authentication

This would allow the same functionality to be used both for internal operational visibility and external service-status communication.

Why This Could Be Useful

IncidentRelay already covers alerting, escalation, heartbeats and incident-response workflows.

A lightweight independent Status Page could add another useful operational capability without requiring organizations to deploy a separate status-page or uptime-monitoring system.

A simple first implementation could focus on:

Status Pages
     ↓
Components
     ↓
HTTP / TCP / ICMP checks
     ↓
Current Status + History

Additional integrations with Heartbeats, Services, Maintenance, Alerts and Incidents could then be added gradually if they fit the project direction.

Would something like an independent Status Page / health-check functionality fit the future direction of IncidentRelay?

[Aidaho12]

These features has RMON, probably it will fit you

[Artesfrost]

Thanks, I’ll take a closer look at RMON.

For the active health checks part, RMON probably fits well.

The main part of the proposal I was interested in, though, is the Status Page itself — an entity/page where we could define service components and display their current status and history, for example:

• Operational
• Degraded
• Partial Outage
• Major Outage
• Maintenance

RMON could actually be a good source of health data for such components instead of implementing another health-check engine inside IncidentRelay.

Do you think a Status Page based on RMON checks / IncidentRelay services could make sense, or would you prefer to keep this functionality completely on the RMON side?

[Aidaho12]

We plan to do IR status page, but without additional checks. I mean only showing status of service/business services

[Aidaho12]

There wasn't page about status page, so we created it https://rmon.io/howto/status-pages