Monitoring & repair
After launch the same agent that deployed your application keeps watching it. It samples health continuously, correlates logs and metrics when something drifts, applies a fix, and writes a report you can read in the morning.
Endpoint health, error rates, latency percentiles, worker liveness, queue lag, database and cache metrics — sampled every few seconds.
Signals are correlated: a latency spike plus pool-exhaustion log lines plus a recent deploy points at a cause, not a symptom.
Restart, roll back to the last verified release, re-provision a degraded server, tune a setting, or redeploy — chosen by diagnosis.
Every repair is checked the same way a deploy is: probes must pass before the incident is marked resolved.
Time, cause, action, outcome and the metrics before and after. Delivered to the incident log and, optionally, your chat tool.
Repeated incidents raise recommendations — a bigger pool, a larger cache, a missing index — that you can accept with one click.
| Symptom | Typical diagnosis | Repair action |
|---|---|---|
| p95 latency climbs after deploy | Connection pool exhausted | Raise pool size, rolling restart |
| 5xx rate spikes | New release crashing on a code path | Roll back to last verified release |
| Worker stops consuming | Process hung / OOM | Restart worker, resize if memory-bound |
| Queue lag grows | Too few workers for load | Add worker servers within bounds |
| Cache hit rate drops | Redis evicting under memory pressure | Recommend resize; enable persistence if queue-backed |
| Health probe fails on one server | Degraded host | Drain, re-provision, re-verify |
| Migration fails during deploy | Schema conflict | Block promotion, keep previous release, report error |
Repairs are limited to operational actions on infrastructure the platform manages. The agent never edits your source code or commits to your repository. Per service you can choose auto-repair, repair with notification or notify only. Rollbacks always target a release that previously passed verification.
! 02:14:07 api p95 4.8s (baseline 180ms) err 0.4% → 02:14:20 correlated: pool_timeout ×312 in api logs; release r-0417 promoted 02:09 → 02:14:31 diagnosis: pool size 10 insufficient after new /search route → 02:14:33 repair: DATABASE_POOL_SIZE 10→30, rolling restart api ×3 ✓ 02:16:02 verified: p95 176ms, err 0.0% · report sent
Connect a repository and let the agent take the 2 a.m. shift.