Services and environments
Carry the change into production with connected service context.
ServicesEnvironmentsDORARollback
Every deploy, and whether it held.
What shipped, where it went, who wrote it, and how the service behaved afterwards. The four DORA metrics fall out of that record on their own.
Deploy frequency
14/day
Lead time
3.2h
Change failure
6%
MTTR
41min
Deployments sit at the heart of Release.
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
Release
Carry the change into production.
Available now
Deployment history
Review deployment evidence beside the service and environment it affected.
Feature flags
Keep rollout controls visible beside release context.
Automatic changelogs
Carry the change into production.
The record, not the orchestrator
lube is the memory of your deploys. It does not run them. Your deploy data arrives from GitHub Actions or the API, and we keep the whole story: the status trail, the commit range, the health verdict, and the uptime that followed. Keep your pipeline. We keep the receipts.
One feed for the whole org.
Every deployment across every product and environment lands in one append-only stream — what shipped, where, who wrote it, and its status the moment it changes.
deploy streamlive
- checkout-v2 → productionv2.5.0 · dana · 2m agoin progress
- web → productionv8.2 · sam · 14m agosuccess
- billing-api → stagingv1.9 · priya · 38m agosuccess
- worker → productionv3.4 · alex · 1h agorolled back
- api-primary → previewv2.5.0 · dana · 2h agosuccess
Deploy activity, banded and stacked.
Count deploys per time bucket, banded by service or by environment, with a ranked breakdown legend. Pin any series to isolate it — the cut is shareable in the URL.
deploys / bucketby service
Mon 30Tue 1Wed 2Thu 3Fri 4Sat 5Sun 6Mon 7
- api-primary
- web
- billing-api
- worker
- other
DORA, derived from the record.
Every figure is computed from your real deploy record — nothing is hand-entered. Read-time and backfill use identical logic, and each metric is reported across org, product, and service. Numbers shown elsewhere are illustrative.
- Deployment frequency
- Successful deployments divided by the days in the window. Shown per day, with a per-week sublabel and a sparkline of the per-bucket counts.successful / windowDaysper day + per week
- Lead time for changes
- The median time from a deploy's earliest commit to its pipeline finish, taken across successful deploys that carry commit data.median secondsn/a without commit data
- Change failure rate
- Failed, errored, and faulty-but-successful deploys divided by counted terminal deploys. Inactive, cancelled, and rolled-back deploys are excluded from the denominator.Healthy ≤ 15%Elevated ≤ 30%High
- Time to restore
- The mean time from a failed or faulty outcome to the next clean success in the same product × environment × service.mean secondsn/a without recoveries
Every service, every environment, one version grid.
Read what is live where at a glance: each cell is the deployed version, colored by health, so a stale prod or a stuck staging jumps out.
servicedevstagingprodpreview
api-primarynode2.4.12.4.12.3.92.5.0
webnext.js8.18.18.08.2
billing-apigo1.91.91.8—
workernode3.33.33.33.4
More than a green checkmark.
Queued to live, with the clock.
Each deploy records its transitions and their timing, so the whole run reads as a stepper — and the trail behind it is append-only.
queued → liveper-stage durationsequenceNumber
Queued
09:42
Building
1m52s
Deploying
2m08s
Verifying
0m41s
Live
—
Append-only status events: each transition adds a row with a strictly increasing sequence number; finishedAt and durationMs land on the terminal event.
Many CI labels, one service.
Aliases fold github_actions, api, and manual labels into a single stable service, each with its own typed environments.
aliasestyped environmentspreview URLs
- api-primarynode · 4 envsgithub_actionsapiapi-primary
- webnext.js · 4 envsgithub_actionsvercelweb
- billing-apigo · 3 envsapimanualbilling-api
- workernode · 3 envsgithub_actionsworker
A rollback is just a linked deploy.
When you revert, the restoring deploy links back to the one it brought back and pins itself as current. The trail stays append-only.
append-onlysupersededrestored
checkout-v2 · production
#4819
2.3.9 ok
#4820
2.4.0 bad
rolled back
#4821
2.3.9 back
current
#4821 restored the last healthy deploy and superseded #4820
Every deploy ships a receipt.
Each deploy captures the commit range since the last success, with the author and pull request behind every change.
commit rangeauthorpull request
checkout-v2 → production#4821
- feat: new checkout flow#4821 · dana
- fix: tax rounding#4818 · sam
- chore: bump deps#4815 · renovate
since last success3 commits
A deploy opens a verification window.
For a window after each deploy, we watch your uptime incidents. Anything that starts inside the window is correlated to the deploy and flags it faulty — the correlation, surfaced, not the cause, inferred.
#4820 · web → productionflagged faulty
deploy+30m window
- Checkout latency spikemajor
- 5xx on /payminor
Incidents that start inside the window flag the deploy faulty. We surface the correlation — we don't infer the cause.
Services and environments, first-class.
Every service, its product, its health.
Each service carries the product it belongs to, its live health, the environments it spans, and its DORA-derived cadence — filter, sort, and search the whole catalog.
associated productshealthdeploy cadence
- api-primaryCheckout · 4 envs18deploys / wk
- webStorefront · 4 envs24deploys / wk
- billing-apiBilling · 3 envs9deploys / wk
- workerPlatform · 3 envs12deploys / wk
Typed environments, production marked live.
Define production, staging, preview, and more, each typed and colored, with the currently deployed version and today's deploy count. Production changes are guarded.
production · staging · previewdeploys todayprod-change guard
- productionproductionliveapi 2.4.1 · web 8.23deploys today
- stagingstagingapi 2.5.0 · web 8.311deploys today
- previewpreviewper-PR27deploys today
- developmentdevelopmentapi 2.5.142deploys today
How the record fills
Deploys arrive from GitHub Actions or a single POST to the report API — one call per deploy, idempotency-keyed so retries never double-count, carrying up to five hundred commits and your own metadata. Status transitions stream in as they change. lube keeps your pipeline exactly as it is and records the outcome.
Modeled on how deploys really vary.
A deployment is not one shape. lube records the strategy, trigger, provider, and health so the record matches reality.
Status
The lifecycle.
queuedin_progresssuccessfailurerolled_backinactive
Strategy
How it rolled out.
basicblue_greencanaryrolling
Trigger
What kicked it off.
pushmanualapipromoterollbackschedule
Provider
Who reported it.
github_actionsapimanual
Health
Post-deploy verdict.
unknownhealthydegradedfaulty
Timing
Recorded per deploy.
queuedAtstartedAtfinishedAtdurationMs
See what surrounds a deployment.
Know whether the last deploy held.
Start free
Start with one service and follow it through.