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, multi-step, 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.
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 moreHTTP, multi-step login and checkout flows, DNS, TLS, TCP, cron heartbeats and queue workers, with maintenance windows.
- Status pagesPublic status pages on your own domain, with component groups, incident and maintenance updates, subscriptions and monthly uptime reports.
- Services you depend onThe status of GitHub, Cloudflare, DigitalOcean and other providers beside your own checks.
Telemetry
Follow a request through the system
The application signals that explain what users see.
- Errors and issuesExceptions grouped into issues with their releases, assignments and a daily digest, and tickets in GitHub, Linear or Jira.
- Laravel packageOne composer package records requests with their timeline, exceptions, slow and N+1 queries, jobs, scheduled tasks and logs.
- Browser errorsJavaScript errors from your visitors’ browsers, grouped into issues beside server errors.
- Traces and metricsOpenTelemetry traces, logs and metrics, a service map, a metrics explorer and dashboards.
- Server logsSystem and Laravel logs from your servers, sent by a small agent and searchable beside traces.
- ReleasesDeploys from Deploy (or your pipeline) mark releases, and every trace shows the deploy that served it.
Respond
Turn important signals into clear work
Explicit alert conditions, routed notifications and a timeline for every incident.
- Alerts and escalationsAlert rules and service-level objectives, email, Slack and webhook destinations, and escalation steps.
- Alerts you can trustAlerts on matching log lines and on error-budget burn, and a noise report that finds the alerts that flap or get ignored.
- Incidents and on-callTimelines with acknowledgements and notes, post-mortems drafted from the timeline and recent deploys, on-call rotations, and push, text and phone alerts.
A practical path through Monitoring
Instrument. Detect. Respond.
Put availability, telemetry and the team’s response into a practical sequence.
- Instrument the serviceCreate an application, add an ingestion key, and send telemetry or OpenTelemetry data.
- Track availabilityAdd checks and heartbeats, and record maintenance windows before planned work.
- Respond and learnRoute 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.
Build and shipDeployRelease from Git to your own servers, with previews, approvals and a recovery point for every deploy.Servers you ownInfrastructureCreate servers in your own cloud accounts, host websites on them, and keep them backed up.Understand your audienceAnalyticsSee how visitors find your site, what they read, and which visits turn into outcomes.Protect what you runSecurityScan your apps, servers and domains for vulnerabilities, leaked secrets and attacks, and fix what matters first.See it as visitors doAuditWatch a simulated visitor use your site and your competitors’, and see what to improve, with pictures.
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.