Group checks by customer-facing workflow, not by server hostname.
Menu
Product
Resources
Tools
PricingLog inFeature · Status communication
Service components for public status pages
Turn raw monitors into customer-readable services so status pages explain impact without revealing internal infrastructure.
HTTPDNSSSLAPI
Reliable visibility without exposing internal infrastructure.
Show operational, degraded, maintenance, and outage states clearly.
Keep private control panels, origins, ports, paths, and provider IDs internal.
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.
Component naming
Use names customers understand: Main website, Client portal, API, Email notifications, Support desk, or Billing portal.
Monitor mapping
A component can represent one critical check or a group of checks when the public impact is the same.
Public boundary
Components should describe what users experience. Internal diagnosis, probe nodes, and server topology belong in admin notes.
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.