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.
Engagement
Client engagement — live production instance
The problem
What this replaced
The manual process, before
- 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 consultant or small team keeping a client's deployed application healthy without the bandwidth to triage every report manually.
Why it costs money
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 workflow. The agent opens an SSH session to the EC2 host, scoped to non-destructive commands only, runs diagnostics, determines the root cause, and posts a report back to the issue. If code needs to change, it says what should change — and stops there.
Turn a reported symptom into a clear diagnostic report automatically, with a hard architectural guarantee that the agent cannot make an unsupervised change.
Capabilities
- GitHub issue-triggered execution via Actions
- SSH diagnostics under a restricted, non-destructive command set
- Root cause determination from live system state
- Suggested-fix reporting — never applied
How it runs
The workflow
Trigger
A GitHub issue describing an observed problem.
- 01GitHub Actions workflow fires on the new issue
- 02Agent opens a limited-scope SSH session to the EC2 host
- 03Runs diagnostics — service status, logs, disk and process checks
- 04Analyzes output to identify the root cause
- 05Determines what the fix should be, without making it
Output
A root-cause diagnostic report posted back to the GitHub issue, including a suggested fix where relevant, with nothing applied.
Architecture
How it fits together
Components
- GitHub issue (trigger) + GitHub Actions
- Diagnostic agent
- Restricted SSH channel — non-destructive allowlist
- AWS EC2 production instance
Data flow
01
Issue opened → Actions triggers agent
02
Scoped SSH → diagnostic commands only
03
Analyze → determine root cause
04
Report + suggested fix → posted to the issue
The guardrail
What it is not allowed to do
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.
In active use on a live client application.
Limited availability
Tell me the problem.
I’ll tell you if an agent is the answer.
A 30-minute call, no pitch. Describe the manual loop that hurts and I’ll give you a straight read on whether this is worth building — including when the honest answer is a script, not an agent.
30 minutes · video call · no pitch