Skip to main content
Status pages provide transparent communication about your service health and incidents to customers, users, and stakeholders. Checkly’s status pages automatically reflect your monitoring results and create a professional interface for incident communication. Status page example

​
Core Status Page components

​
Services

A service represents a functional piece of your application or website, such as landing page, API, support portal etc. You manage your services from the service overview page, accessible in the sidebar.
The number of services and subscribers you can have varies by plan. View pricing
When naming a service, use a name that is identifiable for your users, as this is used when sending out incident notifications. Services are what connect checks and status pages. A service can listen to multiple checks and automatically opening incidents whenever one of these checks trigger a check failure alert. See incident automation for more details. A service can be used by multiple status pages. When an incident is opened for a service, it will appear on all pages that use it. Subscribers of each of those pages will receive email notifications for the incident. Services diagram

​
Connecting services and status pages

To display a service on a Status Page, go to the Status Page editor and open the Services dropdown on the card you want to display your service on. Select your service from the list and save your Status Page. The page will now display the selected service. You can also create new services directly from the dropdown by entering a new service name and pressing Create. You can display the same service on multiple pages. An incident declared on that service will be shown on all status pages which contain that service.

​
Connecting services and checks

Use incident automation to connect a service and a check to automatically open incidents for services based on check alerts. See Incident automation for details.

​
Best practices for status pages

​
Service organization

Create services that align with how your users think about your application: 
# Good service examples
Frontend Application:
  - Website loading and navigation
  - User interface responsiveness
  - Client-side functionality

API Services:
  - Core API endpoints
  - Authentication services
  - Data processing capabilities

Third-party Integrations:
  - Payment processors
  - Email delivery services
  - External data sources
Create services to match how your users perceive your system, not according to your internal architecture. Users care about “Login” working, not whether your “Auth microservice cluster” is healthy.

​
Incident communication

When an incident occurs, provide clear updates that explain what’s happening and how it affects users. Write in plain language, avoiding technical jargon unless your audience is technical. Update the incident as you learn more about the issue, and close it with an explanation of what was fixed. Where possible, communicate proactively to maximize chances to warn users before they encounter problems themselves.