# Deployment History and Auditing

Source: https://www.jawsdeploy.net/guides/deployment-history-and-auditing

Every deployment writes a record - what release, what environment, who triggered it, how long it took, what the steps did.

Jaws Deploy records every deployment. The record covers what (release version), where (environment, targets), when (start/end timestamps, step timings), who (the user or service account that triggered it), and how (the live log of each step's output).

## What's in the record

- **Release**: The release version that was deployed. Linked to the release page with package versions and variable schema.
- **Environment**: The environment the deployment ran against. Resolved targets and scoped variables for that environment.
- **Timing**: Start, end, total duration. Per-step duration. Useful for spotting performance regressions.
- **Initiator**: The user or service account that triggered the deployment, plus the approver if approvals were required.
- **Step outcomes**: Per-step status (pass/fail/skipped), per-target output, full log captured live.
- **Failures**: The failing step, the failing target, the error message - all surfaced before drilling into the log.

## What this is good for

Incident response is the most common use. "What changed between Tuesday's deploy and Friday's?" becomes a diff of releases. "Did this release reach Production?" is one query. "Who approved last month's Production deploys?" is a filter.

The second use is audit. Compliance frameworks that require evidence of segregation-of-duty, approval trails, or change records draw on this data directly.

> **// Retention - History is kept indefinitely unless you choose to expire it.**
> 
> Cloud workspaces keep deployment records for the lifetime of the workspace. Stack installations control retention through database backup/archive policies - the data lives in your database.