Deploy Output Monitoring

Deploy output monitoring catches errors that builds cannot see. Builds check your code before it runs — compilation, types, linting. Deploy monitoring catches what only shows up when the application is actually serving requests: unhandled exceptions, database connection failures, HTTP 500 errors, and startup problems.

Deploy Methods

Xedant Agent supports two deployment methods, each with its own monitoring behavior:

Debug Deploy (Local)

Debug deploys run your application as a local process. With shallowCopy enabled (the default), changed files are copied to a temporary folder before launch — this isolates the application from your source code and lets it be rebuilt without file locking conflicts. Output streams arrive line by line over stdout/stderr, are written immediately to .xedant/deploy/{name}.log, and are broadcast to the UI in real time via SignalR — the channel that pushes live updates from the server to your browser.

Process management — PID files (small files recording the operating system’s process IDs) track running processes; at startup, stale processes left over from previous sessions are cleaned up automatically;
Log size limit — logs are capped at 500MB; when the cap is reached, the log is cleared and the deployment restarts itself;
Build watching — a deployment can watch builds: when every watched build completes successfully, the deployment restarts with the new code.

Docker Deploy (Remote)

Docker deploys ship your application to a remote server over SSH and rsync (SSH runs commands on another machine, rsync copies files to it), then build and run it as a container — a self-contained package that runs the same way everywhere. The process runs as numbered steps, each recorded with its output, and the final container state is verified with health checks.

⚠️ Experimental feature — Docker Deploy has not been thoroughly tested yet. Use it with care and please report bugs. The author himself runs only debug deploys inside isolated Docker containers — that is easier to manage and no less secure.

SSH + rsync — files are transferred to the remote server, excluding patterns such as .git, node_modules, and .xedant;
Container lifecycle — pulls the base image, removes the old container, builds a new one, and starts it with the configured ports, volumes, networks, and environment variables;
Health checks — after deployment, verifies that the container is running and, optionally, checks an HTTP health endpoint;
Per-command timeout — every step runs under the configured timeout; a step that exceeds it has its process killed and the deployment fails.

Deploy Output Parsing

Runtime output is parsed in real time by .xedant/deploy.parser, which uses the same [ERROR]/[/ERROR] block format as the build parser. The patterns cover typical runtime errors:

Unhandled exceptions — full stack traces starting with “Unhandled exception.”;
System exceptions — indented stack traces for .NET, Java, and other platforms;
Log-level errors — lines starting with crit:, fail:, or err: (Serilog/ILogger format);
HTTP errors — responses with status code 500;
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

⚠️ Do not edit parser files by hand — ask the AI model to do it for you. The easiest way: select unrecognized text in the deploy output (the Status Panel or the deploy dialog) and click the floating Fix deploy.parser button — the model receives the selected text with a ready-made prompt and updates deploy.parser. Alternatively, use .xedant/README.md as a hint in the chat.

Comment lines starting with # are ignored;
Single-line patterns — a regular expression (a text-matching pattern) that must match exactly one output line;
Multi-line patterns — wrapped in {{...}}, they capture zero or more consecutive lines after the inner regular expression.

# 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: for each output line it walks the blocks in order and applies their patterns. When all of a block’s patterns match in a row, those lines are pulled out as a single error and the parser moves on. Earlier blocks take priority — once a match is found, later blocks are skipped for those lines.

Warnings are parsed the same way: log-level warnings, deprecation notices, and obsolete API usage. To add your own patterns for your application’s error format, ask the model to update deploy.parser — it reloads automatically on save.

Displaying Deploy Output

Deploy output can grow enormous — a chatty application or a long-running process can produce megabytes of logs. Rendering all of that in the browser would make the page sluggish, balloon memory use, and eventually crash the tab. So measures are taken on both the server and the client to keep the UI responsive no matter how much output there is.

Server-Side Measures

Log file cap — debug deploy logs are limited to 500MB; when the limit is reached, the log is cleared and the deployment restarts itself, so the disk never grows without bound;
Output truncation — when log files are read, only the last 100KB is served; earlier content is dropped with a truncation marker, so the browser never receives the whole history;
SignalR throttling — real-time output is buffered and delivered in batches every 100ms rather than one line at a time as it arrives — fewer messages and no stream of tiny updates;
Incremental streaming — during an active deployment, output arrives line by line as it is produced, and the client appends new lines to the existing buffer instead of replacing the whole output each time.

Client-Side Measures

Inline panel limit — the Status Panel shows only the last 200 lines of output, staying light no matter how large the log is;
Dialog limit — the output dialog shows up to 2000 lines (the end of the log) — enough to see the latest errors and their context without straining the browser;
Chat send limit — when output is sent to the chat for AI analysis, the content is capped at 20KB so the conversation context does not bloat;
Incremental append — the client appends new lines to the buffer instead of replacing the whole output on every SignalR update, keeping redraws to a minimum;
Parsed output caching — discovered errors and warnings are precomputed into a map and reused, so the parser does not rescan the entire output on every screen refresh.

The Deploy Dialog

The output dialog opens when you click a deployment’s name in the Status Panel. It has three tabs:

Log — raw, unfiltered output: the last 2000 lines for debug deploys, or the full step-by-step log for Docker;
Errors — parsed error entries highlighted in red;
Warnings — parsed warnings highlighted in yellow.

Every tab has copy and send-to-chat buttons. Sending errors wraps them in a deploy.log code block so the model can analyze the failure and suggest a fix. Select text in any tab and a floating Fix deploy.parser button appears, for quickly updating deploy.parser when an error format is not recognized.

The Automatic Restart Pipeline

Deployments restart automatically when every watched build has completed successfully — giving you a continuous build → deploy → monitor pipeline:

The model edits project files;
Changes trigger the relevant builds after their configured delay;
The build parser extracts errors and warnings from the output;
AutoFix feeds errors back to the model for fixing (the loop repeats until the builds pass);
When all builds have passed, the deploy service is notified and restarts the application;
The deploy output is parsed in real time for runtime errors.

This pipeline runs without you. You can watch it in the Status Panel or simply check the results later. For debug deploys, an optional url field in the configuration adds a clickable button that opens the application directly — no need to remember the debug instance’s address and port.

Effective Validation Practices

Use deploy monitoring together with builds — builds catch static errors, monitoring catches runtime errors. You need both for full coverage;
Add parser patterns for your application — if your application writes errors in its own format, add patterns to deploy.parser so they show up on the Errors tab;
Send errors to the chat — see a deploy error, click “Send”, and the model will analyze the stack trace and propose a fix;
Watch the log size — debug deploy logs are capped at 500MB. If your application is very chatty, tune the log levels or raise the limit.

The complete deploy reference is on the Build & Deploy page, the automatic error loop in AutoFix, and preventing manual restarts in Model Control with Hooks.

← Sound Feedback Validation

Model & Skills Control →