# Deployment History & Insights

Source: https://www.jawsdeploy.net/features/deployment-history

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.

> **// The audit question this answers - "Was the fix for CVE-2026-1234 deployed to Production before April 12?"**
> 
> With deployment history, the answer is a search, not an archaeology dig. Filter deployments by project, environment, and date range. Look at the release version. Look at what was in it. Move on. The same question without history takes a half-day and an apologetic email.

## 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:

## 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.

## 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.

**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.

**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.