---
title: "Deploy Output Monitoring"
id: "582"
type: "page"
slug: "deploy-output"
published_at: "2026-06-03T14:29:15+00:00"
modified_at: "2026-06-11T15:43:09+00:00"
url: "https://xedant.com/code/docs/validation/deploy-output"
markdown_url: "https://xedant.com/code/docs/validation/deploy-output.md"
excerpt: "Deploy output monitoring catches runtime errors that build-time validation cannot. While builds catch compile errors,…"
---

# Deploy Output Monitoring

[https://xedant.com/code/docs/validation/deploy-output.md](https://xedant.com/code/docs/validation/deploy-output.md)

Deploy output monitoring catches runtime errors that build-time validation cannot. While builds catch compile errors, type mismatches, and lint violations before the code runs, deploy monitoring catches the errors that only appear when your application is actually serving requests — unhandled exceptions, database connection failures, HTTP 500 errors, and startup crashes.

![Deploy output control](https://xedant.com/wp-content/uploads/2026/06/deploy-output-control.png)## Deploy Methods

Xedant Code supports two deployment methods, each with different monitoring characteristics:

### Debug Deploy (Local)

Debug deploys run your application as a local process. With `shallowCopy` enabled (the default), changed files are copied to a temporary directory before the process starts, providing isolation from your source tree and enabling app rebuilds without file locking issues. Output streams line-by-line via stdout/stderr, written immediately to `.xedant/deploy/{name}.log` and broadcast in real-time to the UI through SignalR.

- **Process management** — PID files track running processes. On startup, stale processes from previous sessions are cleaned up automatically
- **Log size limit** — Deploy logs are capped at 500MB. When exceeded, the log is cleared and the deploy restarts automatically
- **Build watching** — Deploys can watch build names. When all watched builds complete successfully, the deploy restarts with the new code

### Docker Deploy (Remote)

Docker deploys push your application to a remote server via SSH and rsync, then build and run it as a container. The deployment process executes as a series of numbered steps, each logged with stdout/stderr, and the final container status is verified with health checks.

**⚠️ Experimental feature** — Docker Deploy is not yet thoroughly tested. Use it with care and please report bugs if any. The author uses only debug deploys in Docker-isolated containers, which is easier to manage and is not less secure than Docker deploys.

- **SSH + rsync** — Source files are transferred to the remote server, excluding patterns like `.git`, `node_modules`, and `.xedant`
- **Container lifecycle** — Pulls the base image, removes the existing container, builds a new image, and runs it with configured ports, volumes, networks, and environment variables
- **Health checks** — After deployment, verifies the container is running and optionally checks a health endpoint via HTTP
- **Per-command timeout** — Each deployment step has a configurable timeout. If a step exceeds it, the process is killed

## Deploy Output Parsing

Runtime output is parsed in real-time using `.xedant/deploy.parser`, which shares the same `[ERROR]`/`[/ERROR]` block format as the build parser. Patterns cover common runtime error categories:

- **Unhandled exceptions** — Full stack traces starting with “Unhandled exception.”
- **System exceptions** — Indented stack traces for .NET, Java, and other framework exceptions
- **Log level errors** — Lines starting with `crit:`, `fail:`, or `err:` (Serilog/ILogger format)
- **HTTP errors** — Status code 500 responses
- **Connection failures** — “Connection refused”, ECONNREFUSED, timeouts
- **Database exceptions** — SqlException, NpgsqlException with indented stack traces
- **Application startup failures** — “Application startup exception” with continuation lines

### Parser Format

⚠️ Don’t try to edit parser files manually — ask the AI model to do it for you. The easiest way: select any unparsed text in deploy output (Status Panel or deploy dialog) and click the floating **Fix parser** button — it sends the selected text to the AI with a properly formatted prompt to update `deploy.parser`. Alternatively, use `.xedant/README.md` as a reference in chat.

- **Comment lines** starting with `#` are ignored
- **Single-line patterns** — A regex that must match exactly one output line
- **Multi-line patterns** — Wrapped in `{{...}}`, matches zero or more consecutive lines that follow the inner regex

```
# Unhandled exceptions with stack traces
[ERROR]
Unhandled exception.*
{{^\s+at\s+}}              # Matches zero or more lines starting with whitespace
[/ERROR]

# Serilog/ILogger error levels
[ERROR]
(crit|fail|err):.*
[/ERROR]

# Warnings
[WARNING]
(warn|warning):.*
[/WARNING]
```

The parser works sequentially: at each output line, it tries each block’s patterns in order. When all patterns in a block match consecutively, those lines are extracted as one error and the parser advances past them. Earlier blocks take priority — once a match is found, later blocks are skipped for those lines.

Warnings are parsed similarly — log level warnings, deprecation notices, and obsolete API usage. To add custom patterns for your application’s specific error format, ask the AI model to update `deploy.parser`. The parser reloads automatically on save.

## Deploy Output Display

Deploy output can grow very large — a chatty application or long-running process can produce megabytes of log data. Without safeguards, rendering all of that in the browser would cause sluggish scrolling, high memory usage, and eventually tab crashes. Several measures are applied at both the server and client level to keep the UI responsive regardless of output volume.

### Server-Side Measures

- **Log file cap** — Debug deploy logs are limited to 500MB. When the limit is reached, the log is cleared and the deploy restarts automatically, preventing unbounded disk growth
- **Output truncation** — When reading log files (e.g. on page load or dialog open), only the last 100KB is served. Earlier content is discarded from the response with a truncation marker, so the browser never receives the full history
- **SignalR throttling** — Real-time output is buffered and broadcast at 100ms intervals rather than sending every individual line as it arrives. This reduces the number of SignalR messages and avoids flooding the browser with tiny updates
- **Incremental streaming** — During active deploys, output is sent line-by-line as it’s produced, not as complete snapshots. The client appends new lines to its existing buffer instead of replacing the entire output on every update

### Client-Side Measures

- **Inline panel limit** — The Status Panel shows only the last 200 lines of deploy output. This keeps the panel lightweight and responsive even when the full log is much larger
- **Dialog limit** — The deploy output dialog shows up to 2,000 lines (the last portion of the log). This is enough to review recent errors and context without straining the browser
- **Chat send limit** — When sending deploy output to the chat for AI analysis, content is capped at 20KB. This prevents oversized messages from consuming excessive context in the conversation
- **Incremental append** — The client appends new output lines to the existing buffer instead of replacing the entire output on each SignalR update, minimizing DOM updates and reactive re-computation
- **Parsed output caching** — Error and warning highlights are pre-computed into a lookup map and reused, so the parser doesn’t re-scan the entire output on every render

## The Deploy Dialog

The deploy output dialog is shown when you click deploy name in the Status Panel, providing three tabs for reviewing deploy output:

- **Log** — Raw, unfiltered runtime output. Shows the last 2000 lines for debug deploys, or the complete step-by-step log for Docker deploys
- **Errors** — Parsed error entries highlighted in red, extracted from the deploy parser
- **Warnings** — Parsed warning entries highlighted in yellow

Each tab has copy and send-to-chat actions. Sending deploy errors to the chat wraps them in a `build.log` code block so the AI can analyze runtime failures and suggest fixes. Selecting text in any tab reveals a floating **Fix parser** button to quickly update `deploy.parser` for unrecognized error formats.

## Automated Restart Pipeline

Deploys restart automatically when all watched builds complete successfully, creating a continuous build-deploy-monitor pipeline:

1. AI modifies project files
2. File changes trigger the relevant builds after their configured delays
3. Build parser extracts errors and warnings from build output
4. [AutoFix](/code/docs/autofix) feeds any errors back to the AI for fixing (cycle repeats until builds pass)
5. When all builds pass, the deploy service is notified and restarts the application
6. Deploy output is parsed in real-time for runtime errors

This pipeline runs without intervention. You can monitor it in the Status Panel or check back later to review the results. For debug deploys, an optional `url` field in the configuration shows a clickable button that opens the deployed application directly. This way you don’t need to remember debug instance address or port.

## Effective Validation Patterns

- **Use deploy monitoring alongside builds** — Builds catch static errors; deploy monitoring catches runtime errors. Both are needed for complete coverage
- **Add application-specific parser patterns** — If your app logs errors in a custom format, add patterns to `deploy.parser` so they appear in the Errors tab
- **Send runtime errors to chat** — When you see deploy errors, click Send to let the AI analyze the stack trace and suggest a fix
- **Monitor the log size** — Debug deploy logs are capped at 500MB. If your application is very chatty, consider adjusting log levels or increasing the limit

For the complete deploy feature reference, see [Build & Deploy](/code/docs/build-deploy)
. For the automated error feedback loop, see [AutoFix](/code/docs/autofix)
. For preventing manual deploy restarts, see [Hooks: Model Behavior Control](/code/docs/validation/hooks-control)
.

**[← Sound Feedback Validation](/code/docs/validation/sound-feedback)**

**[Model & Skills Control →](/code/docs/validation/model-skills)**