Monitoring

Checks you can trust across regions

Run scheduled and on-demand checks close to your users. Record outcomes, timings, and history in one place before they roll up to components and status surfaces.

Get started Monitoring overview

Check surface

IntervalsOn-demandPer-regionChartsHistory

Recent check attempts by region
Region	Outcome	RTT	Time
eu-central	OK	238ms	11:42:06
us-east	OK	191ms	11:42:06
ap-southeast	OK	312ms	11:42:05

Interval 60sLast run OK · 240ms

History paginated

Problem

Single-region checks miss real user experience

A passing check from one datacenter does not explain latency or failure modes everywhere. Without regional coverage and history, teams guess instead of measure.

Blind spots

Stale snapshots

Weak timelines

Statuslab runs checks through distributed probes, stores structured results, and connects them to components and incidents you already manage.

Checks

Detection built for operators

Define monitors with clear intervals and regions. Pause or resume without losing configuration. Trigger on-demand runs when you need confirmation outside the schedule.

HTTP, DNS, and TCP monitoringManual and scheduled checksPause and resume safelyRegion-based execution

Per-region outcomes and RTT
Paginated check history
Charts where HTTP timing applies

Detection layer in the product model

Check types

Protocols your monitors can use

HTTP
Supported
Method, status, and response timing. TLS and redirect behavior where configured.
GET https://api.example.com/v1/health
TCP
Supported
Connect to host and port. Validates reachability for databases, caches, and internal services.
db.internal.example.com:5432
DNS
Supported
Resolve records and compare against expected values for routing and failover checks.
api.example.com A / AAAA

Scheduled intervalOn-demand runPer-region

Downstream

Monitors feed the rest of the model

Map checks to components so health reflects architecture. Incidents and status pages consume the same structured signals.

Signal to component

Roll monitor state into component rows customers already read on the status page.

Controlled visibility

Choose what surfaces publicly versus what stays in the dashboard.

Same project, one graph

Monitors, incidents, and pages stay under one project boundary.

Public status page Incident management

Region registry

Pools healthy

Probe workers register per region. The control plane tracks heartbeats and routes checks without duplicating configuration.

Probe workersHeartbeatsDrainScheduling

Probe regions and pool status
Region	Label	Probes	Median RTT	Pool
eu-central	Europe	12	38ms	Healthy
us-east	Americas	14	22ms	Healthy
ap-southeast	Asia Pacific	10	51ms	Healthy

Control plane coordinates probes and schedulesRegions 3 · same model as checks

Infrastructure

Distributed probes, coordinated execution

Checks run in regions with healthy probe pools. Workers report heartbeats, drain safely, and keep scheduling predictable as load changes.

Regional probe pools
Health-based coordination
Scalable worker architecture

Infrastructure in context

Data

History and aggregates per monitor

Inspect check history, filter by region, and read aggregated statistics over time. Charts complement raw rows when you need trend context.

Time-based statistics
Region filters
Check history and series

Aggregates

History and aggregates

Last 7 days · successful attempts

Per-region aggregate statistics for a monitor
Region	Window	Samples	Median RTT	P95 RTT	Availability
eu-central	7d	10,240	198ms	412ms	99.94%
us-east	7d	10,188	191ms	398ms	99.98%
ap-southeast	7d	10,112	224ms	468ms	99.91%
All regions	7d	30,540	204ms	426ms	99.94%

Check history is paginated. Filter by region and time range in the dashboard.

Charts & visualization

Latency trends you can read at a glance

P50 and P95 sit on the same time axis so you see typical response time and tail behavior together. The dashboard uses the same chart family as live monitor analytics.

Dual series for median and tail
Bucketed time axis
Tooltips with millisecond precision

Latency

Response time

Median (P50) vs tail latency (P95) per bucket from successful probe attempts.

Illustrative series · same chart family as the monitor detail view

Real-time

Dashboards update as probes finish

New results propagate over the same realtime channel as incidents and status pages. Operators see state change without manual refresh.

WebSocket delivery to project sessions
Shared layer with public pages
Immediate visibility after checks

Realtime layer

WebSocket /status

Connected

Project dashboard
room project:8f3a…c1
Gateway
fan-out to rooms
Public status page
room page:acme

Payload

monitorcomponentincident

Integration with components

Map monitors to what customers already recognize

Attach checks to components so row-level health on the status page reflects real probe results. Grouping, order, and visibility stay under component settings.

One monitor can inform one component row
Roll up or override when automation is not enough
Same names your team uses in the dashboard

Components in the dashboard

Incident integration

From failed checks to structured incidents

When policy says so, a bad run opens or escalates an incident with a clear link back to the monitor that triggered it. Your timeline stays the source of truth for responders and for the public page when you publish.

Triggering monitor on the incidentLifecycle and updatesOptional status page visibility

Incident management

Summary

Monitoring that fits the rest of Statuslab

Distributed checks and structured history connect to components, incidents, and public status in one project.

•Regional execution with clear outcomes
•History and aggregates for triage
•Same realtime path as incidents and pages

Start monitoring with structure

Create an account, add monitors in your project, and connect components when you are ready.

Get started Open monitors