Managing Services
Services are the individual components displayed on your public status page — for example, "API", "Web App", or "Payment Gateway". Each service has a name, URL, and current health status. Visitors see all added services with their status, availability timeline, and optional uptime charts.
Open the Services tab#
- Go to Synthetics → Status Page
- Open an existing page or create a new one
- Select the Services tab
The left panel lists services available in your project. The right panel shows a live preview of how services appear on the public page.
Add a service manually#
1 Create a new service#
Click Add Service and enter:
- Service name — the label shown on the public page (e.g.
Checkout API) - Service URL — the endpoint URL for this component (e.g.
https://api.example.com/health)
Middleware validates the URL format before saving.
2 Add to the status page#
After creating a service, add it to your page so it appears publicly. Services that are created but not yet added remain in your project service list without being visible to visitors.
Add a service from Synthetic Monitoring#
Linking a service to an existing Synthetic monitor is the recommended approach. It enables:
- Live uptime metrics polled from the last 10 minutes of synthetic check data
- 24-hour uptime charts on the public page (unless hidden in settings)
- Automatic status refinement alongside incident-driven updates
To link a synthetic monitor:
- On the Services tab, browse the list of existing Synthetic monitors in your project
- Select a monitor and add it to the status page
- The service inherits the monitor's name and URL, and stores the underlying
check_idlink
When the linked synthetic check fails, the service status reflects degraded or downtime conditions on the public page.
Service status values#
| Status | When it appears |
|---|---|
| Operational | No active incidents affect this service and synthetic checks are passing |
| Degraded | An incident with degraded impact is active, or synthetic data indicates performance issues |
| Downtime | An incident with downtime impact is active, or synthetic checks are failing |
Incident updates take precedence when setting service status. See Managing Incidents for how impact types map to service status.
What visitors see#
For each added service, the public status page shows:
- Current status indicator (operational, degraded, or downtime)
- Availability timeline — historical status changes for the service
- Uptime chart — 24-hour response time and availability data from the linked synthetic monitor (hidden if Hide response time chart is enabled in Settings)
Remove or delete a service#
- Remove from page — stops displaying the service on the public page but keeps it in your project
- Delete — permanently removes the service and its history from the status page
Deleting a service that is linked to a Synthetic monitor does not delete the underlying synthetic check.
Best practices#
- One service per customer-facing component — split API, web app, and background workers into separate services so incidents can target specific areas
- Link synthetics where possible — manual services rely on incident updates alone; linked monitors provide continuous health signal
- Match monitor assertions to SLIs — configure synthetic checks with the same success criteria your customers care about (status code, response time, etc.)
- Name services clearly — use labels your customers recognize, not internal codenames
Next steps#
- Managing Incidents — report issues that update service status
- Synthetic Monitoring — create monitors to link as services
Need assistance or want to learn more about Middleware? Contact our support team at [email protected] or join our Slack channel.