# Live Deployment Logs

Source: https://www.jawsdeploy.net/features/live-deployment-logs

Live logs are streamed from the agent, grouped by step and target, and survive the page reload. You see what is happening, where it is happening, while it happens.

## What "live" actually means

The deployment view in Jaws Deploy is a streaming tree, not a tail of stdout. Each **step** is a collapsible node. Each **target the step runs on** is a child node. Log lines, warnings, and errors appear under the right node as they happen. Refresh the page and the tree is still there - the log is persisted on the server, not buffered in your browser.

> **// Why a tree, not a tail - Twelve targets writing to one stream is unreadable.**
> 
> When a step fans out to twelve machines and they all log at the same time, a flat stdout is useless. The tree lets you collapse the boring ones, focus on the failing one, and still see the overall shape of the deployment. It is the difference between debugging blind and debugging with a map.

## What you see, live, while it runs

- **Step output**: Stdout/stderr from each step, attributed to the right target. Color-coded for warnings and errors.
- **Per-target timing**: Elapsed time per target so you can spot the one slow box without a stopwatch.
- **Step status**: Pending, running, finished, failed, skipped - at both the step level and per target, with error and warning counts rolled up to every node above a line. A step can finish and still carry errors, so read the counts too.
- **Warnings & errors**: Surfaced separately, not buried in the log. Filter to see only what's broken.

## The bits that surprise people in a good way

A few details that show up in evaluator demos and tend to land well:

## Stuff a hand-rolled deployment script will never give you

- **The log survives a browser refresh.** It is server-side. You can hand the URL to a teammate at any point.
- **Logs are addressable.** Every line has a permalink. Useful for incident write-ups and code review.
- **Parallel execution is visible.** When a step runs on five machines at once, you see five lanes filling in, not one merged firehose.
- **Warnings are first-class.** A non-fatal PowerShell warning is not lost in the noise - it shows up in the warnings sidebar and stays attached to the step.
- **Targets that have not started yet are placeholders.** You can see what is *about* to happen, not just what already did.

> **// Performance reality check - Logs are cheap to produce. They are not free.**
> 
> If a step writes 5 MB of output per machine across twenty machines, that is 100 MB of log to stream, persist, and render. The platform handles it, but treat verbose `Write-Host` like you would treat `console.log` in production code: useful while debugging, regrettable as a permanent fixture.

## Tips for writing scripts that read well in the live view

Treat log output as a UI. Future-you, reading this at 2am, is the user.

```
Write-Host "Step: applying configuration to checkout-service"
Write-Host "  target  : $($env:JAWS_TargetName)"
Write-Host "  release : $($env:JAWS_ReleaseVersion)"

try {
    Apply-Config -Path $configPath
    Write-Host "  status  : OK ($(($sw.Elapsed).TotalSeconds.ToString('0.0'))s)"
}
catch {
    Write-Warning "  status  : retrying after transient error: $_"
    Apply-Config -Path $configPath
}
```

## When the deployment fails - and it will

A deployment that hit trouble looks the same in the live view as a clean one, with one important difference: the trouble is **scoped**. Jaws Deploy tells you which step reported the error, on which target, and shows you the log lines immediately above it.

That sounds obvious until you have spent an afternoon scrolling through twelve thousand lines of CI output trying to find which of the eight servers actually rejected the package. With a tree, the red node has a name.

Worth knowing when you read the tree: a step that reported errors still finishes, and so does the deployment. The counts on each node, not the overall status, are what tell you the work went wrong.

**Agent side**

The agent executes the step locally, captures stdout/stderr, and ships log frames to the control plane over the same outbound connection it uses for everything else.

**Browser side**

The live view subscribes to those frames. New lines paint in real time. The tree reshapes itself as steps start and finish.

## Logs and history are the same thing

The live log does not vanish when the deployment finishes - it becomes the deployment record. The same view you watched at deploy time is the one you (or an auditor, or future-you) opens six months later from deployment history. There is no "runtime log" and "archived log" distinction; the live view is the archive.