Ship, verify, roll back
Release markers land on the observability timeline; error rate, latency and log changes line up with that release.
After the release, the work begins
The version is out. Did error rate move, did latency climb, did new exceptions appear? Too often the answer waits for a user to complain.
Diting writes release markers into the observability timeline, so metrics, traces and logs before and after can be compared directly.
One chain
Commit
Code lands, the pipeline triggers.
Build
Image built and pushed to the registry.
Release
Per environment, with visible progress.
Verify
Compare metrics, traces and logs; roll back on anomaly.
Release chainDiting
01Commit
02Build
03Release
04Observe
05Roll back
Releases leave a record
Who shipped, what shipped, where it landed, and what followed.
- Release records
- Environment comparison
- Error rate and latency
- One-click rollback
Fits
- Teams releasing often that need fast impact checks
- Multi-environment delivery
Doesn't fit
- Organizations that forbid the platform from touching build systems
Bring your system in
Tell us what you run: OS, kernel, public network or not, virtual machines or clusters. We will map the path in.