DevOps Diagnostics Agent
A GitHub-issue-triggered agent with SSH into a production EC2 host, a hard allowlist of non-destructive commands, and no authority to fix anything it finds.
- Trigger
- Agent
- Tool / data
- Guardrail
- Human
⊘ This is the whole point of the system.
The problem
What this replaced
- 01Something looks wrong on a production instance.
- 02SSH in. Run diagnostics. Read logs.
- 03Work out the root cause by hand.
Who has this problem
A solo engineer or small team keeping a deployed application healthy without the bandwidth to triage every report manually.
What it costs
Manual triage is slow. But full automation is worse if the automation can change things — the risk of an agent with write access to production outweighs the time it saves.
The build
What I built
A GitHub issue describing the symptom triggers a GitHub Actions workflow. The agent gets read-only access to the application host: a fixed set of bash commands — container logs, memory and disk, service state — that give it the same context an engineer would gather from logs and metrics. From that it works out the root cause and posts a report to the issue, including the fix it would make. The engineer reads it and deploys the fix.
Turn a reported symptom into a root-cause report automatically, with a hard guarantee that the agent cannot change the system it is diagnosing.
Capabilities
- 01GitHub issue-triggered execution via Actions
- 02SSH diagnostics under a restricted, non-destructive command set
- 03Root cause determination from live system state
- 04Suggested-fix reporting — never applied
How it runs
The workflow
- in
Trigger
A GitHub issue describing an observed problem.
- 01
GitHub Actions workflow fires on the new issue
- 02
Agent opens a limited-scope SSH session to the EC2 host
- 03
Runs diagnostics — service status, logs, disk and process checks
- 04
Analyzes output to identify the root cause
- 05
Determines what the fix should be, without making it
- out
Output
A root-cause diagnostic report posted back to the GitHub issue, including a suggested fix where relevant, with nothing applied.
Components
- GitHub issue (trigger) + GitHub Actions
- Diagnostic agent
- Restricted SSH channel — non-destructive allowlist
- AWS EC2 production instance
The guardrail
What it is not allowed to do
⊘ Boundary
This is the whole point of the system.
The agent has real SSH access to a production host — and a command allowlist that makes destructive operations structurally impossible rather than merely discouraged. It can tell you the disk is full and which service should change. It cannot free the disk or change the service. Most agent projects ask how much autonomy they can grant. This one was designed from the opposite direction: establish what it must never be able to do, then give it everything else.
Stack
What it is built on
- Trigger
- GitHub IssuesGitHub Actions
- Access
- SSH — non-destructive command allowlist
- Target
- AWS EC2
- Diagnostics
- systemctldocker logsfreedf
Hard parts
What made it difficult
- 01
Defining an allowlist tight enough to be genuinely safe but broad enough to actually diagnose a real fault.
- 02
Reaching a confident root cause from read-only signals alone.
- 03
Producing a report specific enough to act on immediately, given the agent cannot act itself.
Outcome
What changed
Removes the need to manually SSH in and triage every reported issue by hand.
Automated, issue-triggered diagnostic reporting with a hard non-destructive boundary.
Built and run against a live production application.
Get in touch
Building an agent that has to survive production?
I write about MCP design, evals and guardrails on LinkedIn most days. If you're working on something similar, I'm happy to talk shop.