Show HN: OnCallMate – AI agent for autonomous Docker incident RCA | Hacker News Reader

Show HN: OnCallMate – AI agent for autonomous Docker incident RCA

github.com

1 pointismailperim2 comments

Hey HN! I built this because I got tired of waking up to read Docker logs.

OnCallMate is an autonomous AI agent that: - Monitors your Docker containers (proactive scheduler) - Detects anomalies (crashes, OOM, restarts) - Autonomously investigates using OpenAI function calling - Performs RCA and suggests fixes

Example workflow: User: "any issues?" → AI calls docker_list, docker_inspect (4x), docker_stats (3x), docker_logs → Returns: " CRITICAL nginx - OOMKilled. Memory hit 512MB limit. Recommend: docker update --memory=1g nginx"

Security-first design: - not SaaS/self-hosted - Docker socket proxy (read-only by default, no direct socket exposure) - Admin-only access (Telegram ID allowlist)

AI provider options: - OpenAI/Claude API (you choose what to send) - OpenRouter free tier (cost-effective) - Bring your own model (extensible architecture)

Built in 3 days using: - OpenAI function calling (multi-turn tool loops) - Universal tool architecture (Docker now, K8s and cloud providers later) - TypeScript + Dockerode + Telegram (Slack etc. later)

Open source (MIT), runs entirely in your network.

GitHub: https://github.com/ismailperim/oncallmate

What features would make this more useful for you?

Open articleView on HN

The OOM/restart loop problem is one of those things that eats engineers alive at 2am because the actual root cause is almost never in the container logs themselves — it's usually misconfigured resource limits, noisy neighbors on the node, or a memory leak that only surfaces under specific request patterns. The autonomous RCA angle is interesting but I'm curious whether you're correlating against node-level metrics or just container events, because without that layer you'll chase a lot of false leads.

One thing I've seen bite teams hard at this stage: the investigation agent needs read-only access to work, but most setups end up giving it broader Docker socket permissions "temporarily" and that never gets cleaned up. That's a real blast radius problem if the agent itself gets exploited or misbehaves.

What does your permission model for the agent look like right now?

Great questions - you're right on both fronts.

*Node metrics:* Currently we're container-only (docker stats/logs), so yes - we'd miss noisy neighbors or node-level memory pressure. Prometheus integration is on the roadmap to correlate container events with node/cluster metrics. Right now we catch the obvious cases: "this container OOMKilled at its 512MB limit."

*Permissions:* Funny story - I built this while working with OpenClaw (an AI assistant framework). OpenClaw has broad system access by design, but I wanted to explore: what if we made a micro-agent with the minimum permissions needed?

So OnCallMate offers two modes: 1. *Direct socket* (if you trust it / testing): bind /var/run/docker.sock 2. *docker-socket-proxy* (production): read-only layer, no exec/restart/POST

The proxy approach: - Agent connects via TCP, never touches the socket directly - Whitelist: containers, logs, stats, inspect (GET only) - Blacklist: exec, restart, swarm, secrets - Even if AI hallucinates "docker restart nginx", it physically can't

All tool calls are logged for audit trails.

You're right that we should emphasize this more in the README. Principle: treat AI agents like untrusted input.

Have you seen other patterns for safely exposing Docker APIs to automation?

Reply on news.ycombinator.com