// Observe

Watch the deployment run. Don't refresh the CI page.

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.

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, succeeded, failed - at both the step level and per target. No guessing.

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:

// Quality-of-life things

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.

Prefer structured Write-Host "key=value" over dumping entire objects.
Use -Verbose flags conservatively in deployment scripts.
If you really need verbose output, redirect it to a file the deployment uploads as an artifact.

// What good deployment-step logging looks like

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 failed deployment looks the same in the live view as a successful one, with one important difference: the failure is scoped. Jaws Deploy tells you which step failed, on which target, with which exit code, and shows you the log lines immediately above the failure.

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.

// What runs

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.

// What you see

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.