Service health
Storefront · production
Availability, telemetry and response activity in one service view.
Check history
Last 24 hours- Uptime
- 99.99%
- Latency
- 142 ms
- Objective
- On target
Illustrative interface with sample data.
All services
Understand production · Monitoring
See health, errors and changes together.
Uptime, heartbeat and queue checks, application telemetry and traces, and alerts that turn the signals that matter into incidents.
- HTTP, DNS, TLS, TCP, heartbeat and queue checks
- Errors, traces, logs and metrics
- Alerts, SLOs and escalations
- Status pages with subscriptions
Works with
- OpenTelemetry
- HTTP, DNS, TLS, TCP
- Heartbeats
- Queue workers
- SLOs
- Slack
- Webhooks
Understand production
Follow a service from first signal through recovery.
Availability with history
HTTP, DNS, TLS and TCP checks, queue workers and cron heartbeats, with maintenance windows beside the history.
Application signals together
Traces, metrics, logs and grouped issues, each with the release it arrived in.
A response path for incidents
Route alerts, escalate, acknowledge, and publish updates to a status page.
What Monitoring looks like
Inside Monitoring
What you can do
A closer look at what Monitoring does, grouped by the work it supports.
Checks
Know when a service changes
Scheduled checks with history, recovery and planned work in context.
-
Uptime and more
-
Status pages
Telemetry
Follow a request through the system
The application signals that explain what users see.
-
Errors and issues
-
Traces and metrics
-
Releases
Respond
Turn important signals into clear work
Explicit alert conditions, routed notifications and a timeline for every incident.
-
Alerts and escalations
-
Incidents
A practical path through Monitoring
Instrument. Detect. Respond.
Put availability, telemetry and the team’s response into a practical sequence.
-
Instrument the service
Create an application, add an ingestion key, and send telemetry or OpenTelemetry data.
-
Track availability
Add checks and heartbeats, and record maintenance windows before planned work.
-
Respond and learn
Route alerts to your team, work the incident timeline, and compare against your objectives.
Safety and accountability
Keep signals useful and response traceable.
Control how telemetry arrives, how alerts are routed, and who can see what happened.
- Scoped ingestion keys
- Trigger and recovery conditions
- Cooldowns and deduplication
- Delivery history and retries
- Roles and audit history
- Unchanged ingest endpoints
Better together
Works with the rest of BuildPusher.
- Deploy: Issues and incidents show the release that was live when they started.
- Analytics: Incident windows sit beside the traffic they affected.
Good to know
Straight answers about Monitoring.
What can Monitoring collect?
Scheduled HTTP, DNS, TLS and TCP checks, queue and heartbeat checks, and application errors, traces, logs and metrics, including OpenTelemetry.
Can I share service health publicly?
Yes. Status pages publish the services you choose, with incident updates and email subscriptions.
Do my agents need changing?
No. Ingest, OpenTelemetry, heartbeat and queue endpoints keep their addresses and formats.
Part of BuildPusher
Start with Monitoring.
Every service has a free tier. Turn on the others when a project needs them, on the same account and bill.