Uptime and heartbeats
Know whether the release held with availability checks.
HTTPTCPHeartbeatSSL
Know it's down before they tell you.
HTTP(S), TCP and cron-heartbeat monitors, probed on your interval by a worker fleet. Match status codes and keywords, watch certificates expire, group the fleet, and keep 90 days of history behind every check.
api.lube.work
live up degraded down
Uptime is your reliability early-warning system.
One connected loop, held on the stage this capability serves. The other stages stay as context so you can see what feeds in and what comes next.
BD
Discovery
Feedback
Product
Engineering
Release
Reliability
Evidence
Reliability
Know whether it held.
Available now
Incidents and status pages
Keep incident response and customer-facing status context together.
Web performance
Review Lighthouse report evidence against configured targets.
Test intelligence
Investigate test outcomes and flakiness evidence across runs.
How a check decides
A dedicated worker fleet probes each monitor on its own interval. A failed check is retried a few times, and a monitor only flips to down once it crosses the failure threshold you set — so a single blip never pages you. Every availability figure on this page is illustrative: lube computes uptime from real checks, but nothing here is a measured SLA.
Watch checks stream in and a failure surface itself.
Every monitor runs on its own interval. New checks stream in from the right; when one fails it flips red and pulses while the healthy monitors keep marching.
check feed
streaming- api.lube.workus-eastuplast 30 checks99.98%
- checkout-apieu-westdownlast 30 checks99.71%
- nightly-sync (heartbeat)internaluplast 30 checks100%
HTTP, TCP, or heartbeat — whatever the dependency is.
Probe an HTTP endpoint, open a raw TCP port, or wait for a cron job to check in. Each kind carries exactly the config that makes sense for it.
- httpevery 1m
GET https://api.lube.work/health
Expects 200 and body containing "ok".
- tcpevery 5m
db.internal:5432
Port must accept a connection.
- heartbeatgrace 10m
nightly-sync
Inbound ping before the grace window ends.
Every check, bucketed into history you can range over.
Roll up to the last 24 hours or back 90 days. Each bucket stacks up, degraded and down, with maintenance windows capped out of the math and response min/avg/max underneath.
24h3d7d30d90d
updegradeddownmaintenance
- uptime
- 99.94%
- min
- 88ms
- avg
- 142ms
- max
- 604ms
Every knob, on the record
A monitor is not a single global poll — it is a spec you tune: the interval it runs on, how sure a failure has to be, what a healthy response must contain, and how the fleet is grouped. The bands below are the real knobs, drawn from the create-monitor form.
Tune the cadence, then the meaning.
Set how often, and how sure.
Pick a check interval, then decide how many immediate retries and consecutive failures it takes before a monitor is really down.
1m to 60mretries 0-5failure threshold
check interval
1m5m10m30m60m
- timeout10s (1-30s)
- retries2 (0-5)
- failure threshold3 checks (1-10)
“Up” can mean it returned the right thing.
Match the status code and search the response body for a keyword that must be present — or one that must not.
status 100-599containsnot_contains
GET https://api.lube.work/health
- MethodGET
- Status code= 200
- Body contains"ok"
- Body excludes"error"
Response passed every assertion.
Know before the certificate expires.
Every HTTPS check reads the live certificate and tracks the days left, so an expiry becomes a heads-up on your alert channel, not an outage.
issuer & serialexpiry countdowncert history
34d
to expiry
- IssuerLet's Encrypt
- ExpiresAug 17
- Serial03:a2…f1
Fold the fleet into groups that roll up.
Group related monitors so a dashboard of hundreds still reads as a handful of statuses; a group that is not fully healthy draws the eye.
grouped listrolled-up statussortable
- api-gateway99.99%
- checkout-api97.42%
- auth-service99.61%
- billing-worker99.99%
- nightly-sync (heartbeat)100%
- search-indexer99.98%
- ledger-service99.99%
Four availability windows, already computed.
Every monitor carries 24h, 7d, 30d and 90d availability with maintenance excluded — illustrative figures you can sort the whole fleet by.
24h / 7d / 30d / 90dmaintenance excludedsortable
availability
SLO 99.9%- 24h99.98%✓
- 7d99.95%✓
- 30d99.90%✓
- 90d99.82%!
3
monitor types — HTTP, TCP and cron heartbeat
5
check intervals, from one minute to one hour
5
history ranges, 24 hours out to 90 days
4
rolling availability windows per monitor
The exact shape of a monitor.
No enum is hidden. Every value here comes straight from the create-monitor form and the check schema.
- Monitor types
- HTTP(S), TCP and inbound cron heartbeat.httpheartbeattcp
- HTTP method
- GET, HEAD or POST.GETHEADPOST
- Expected status
- Any code from 100 to 599 (default 200).
- Keyword match
- Up to 500 characters, required present or required absent.containsnot_contains
- Check interval
- 1m, 5m, 10m, 30m or 60m.
- Timeout
- 1 to 30 seconds (default 10s).
- Retries
- 0 to 5 immediate retries (default 2).
- Failure threshold
- 1 to 10 consecutive fails before down (default 3).
- TCP target
- Host plus a port from 1 to 65535.
- Heartbeat
- Token-based inbound ping URL with a grace window up to 24 hours.
- SSL
- Live certificate, expiry and history tracked on HTTPS checks.
- History ranges
- 24h, 3d, 7d, 30d, 90d — up/degraded/down, response min/avg/max, and maintenance coverage per bucket.
- Status
- up, down, degraded, paused or pending.updowndegradedpausedpending
What the numbers mean
Every availability percentage here is computed from real checks but shown as an illustrative figure, never a measured SLA. lube runs one worker fleet today, so the region labels are illustrative context rather than a per-region catalog you configure. When a check does fail, it routes out to Slack, Teams, Google Chat or a webhook.
When a check fails, the rest is already here.
Be the one who already knows.
Start free
Connect one service and its checks to start.