Group public services into readable components.
Feature · Monitoring
Customer status pages for clear updates
Publish branded status pages with components, incident history, maintenance windows, subscribers, and customer-safe explanations.
HTTPDNSSSLAPI
Reliable visibility without exposing internal infrastructure.
Publish incidents and maintenance windows with impact notes.
Keep private infrastructure details out of public descriptions.
Watch the signal
Track the public evidence customers actually experience.
Measure the trend
Keep response, uptime, and incident context close to the decision.
Route the response
Alert the right people and publish customer-safe updates when needed.
Components
Components should describe customer-facing services such as website, client portal, API, or email notifications.
Incidents
Each incident has status updates, impacted components, and a resolution timeline.
Subscribers
Customers can follow updates without repeatedly opening tickets.
Safe for public status pages
- Website and application availability
- API health endpoint status
- DNS and SSL issues affecting customer access
- Maintenance windows and incident timelines
- High-level region coverage
Internal operations only
- SSH, admin panels, databases, queues, and backups
- Server names, origin IPs, provider IDs, and ports
- Firewall rules, file paths, and secret-related config
- Primary or backup probe node details
- Customer-specific private control panels
Related pages
Continue building the monitoring workflow.
Ready to set up the right monitors?
Start with critical customer-facing services, then add status pages, alert routes, and managed help as reliability becomes more important.