// Observe

What shipped, when, where, and why.

Every release is a snapshot. Every deployment is a record. Six months later, you can still answer the question "what exactly went to production on that Tuesday?" without grepping CI logs.

What's recorded

Every deployment in Jaws Deploy writes a structured record. Not a log file in a folder - a queryable record. The record sticks around indefinitely unless you intentionally clean it up.

What you can recover for any past deployment

Package versions The exact artifact versions that went out. Not the source commit - the artifact.

Variable snapshot The variables (with secrets redacted) as they were at deploy time. Not as they are now.

Step-by-step log The same live log you watched, persisted in full, with timing for each step on each target.

Timeline & duration Start time, end time, per-step duration, queue time. Find your slow steps quickly.

Insights you actually look at

The history view is not just an archive - it surfaces patterns that are tedious to spot manually. Things teams notice once they have a couple of months of history:

// What the data tells you over time

Patterns that change how you deploy

Step duration drift. The migration step that used to take 30 seconds now takes four minutes. The chart shows the slope; you decide whether to act.
Failure clustering. "Most deployment failures happen on Monday morning, on Step 7, on machines with role:cache." That is a real fix waiting to happen.
Environment cycle time. The lag between a Staging deploy and the corresponding Production deploy. If it is widening, your release cadence is decaying.
Promotion gaps. Releases that went to Staging but never reached Production. Some are intentional. The ones that are not are interesting.
Rollback frequency. Not as a shame metric - as a signal of test-coverage gaps in specific areas.

// REST API for history

When you want to feed history into your own tooling

The same data the UI shows is available via the REST API. A common pattern is exporting last 90 days into a dashboard your SREs already watch.

GET /api/workspaces/default/deployments
  ?project=checkout-service
  &environment=production
  &from=2026-02-01
  &to=2026-05-01

# returns: deployment id, release version, status, duration,
#         start/end time, step counts, error counts

// The thing nobody plans for

Deployment history is your forensic timeline.

When a production incident happens, the first question is "what changed?" If the answer lives in five places - CI, chat, ticket comments, deploy scripts, someone's memory - the incident is twice as long. If it lives in deployment history with timestamps and per-step status, the postmortem writes itself.

Every deployment has an immutable id you can reference in tickets.
Release notes attached at release-creation time travel with the release forever.
Per-step logs are searchable, so "did the migration run?" is a one-click answer.

// Retention

Records persist

Deployment records are not log files - they live in the database with the rest of the platform state. The default is forever; cleanup is something you do on purpose.

// Privacy

Secrets stay secret

The variable snapshot stored with a deployment redacts secret values the same way the live log does. History never becomes a credentials trove.

A useful test

If you cannot answer "which release was last deployed to Production, and what was in it" in under thirty seconds, your current setup is undercharging you for deployments. That single sentence is what deployment history exists to make trivial.

Everything else - the timing charts, the failure clustering, the auditor-friendly export - is layered on top of that one capability.