LogForge GitHub

// docker.control

Docker alerts that fix themselves

Self-hosted Docker dashboard for local and agent-forwarded logs, alert rules, notifications, file access, safe remediation, and AI agent tasks for Docker operations.

Install LogForge View GitHub

Want the operator walkthrough? Book a demo

logs alert rules notifiers guarded fixes AI agent edge agents

Used by Developers at

Cisco Netflix Microsoft Amazon

// incident.delta

Container incident. Minute one. Without vs with LogForge.

WITHOUT LOGFORGE 45 min

SSH, scroll, guess, restart.

  • SSH into the host after users report errors.
  • Run docker logs and scan for the first useful stack trace.
  • Miss the alert window while checking the wrong container.
  • Run grep to search for the keyword.
  • Manually restart and hope it was the right fix.
WITH LOGFORGE 30 sec

Rule fires, route sends, guard fixes.

  • Alert rule catches OutOfMemoryError and restart loops.
  • Notifier sends to Slack, Discord, Telegram, Gotify, Teams, Pushover, SMS, email, or webhook.
  • Gatekeeper applies cooldown and backoff before restart, stop, kill, start, or script action.
  • AI Agent explains likely cause and suggests scoped fixes before repeated incidents spread.
  • Alert history records the event, action, and final outcome.

// live.pipeline

The operational loop, rendered live.

Docker log tailing is the default collection path on each host or enrolled agent, and agents can forward logs and Docker events into central LogForge. From there, rules match logs, rates, metrics, missing signals, and Docker events; the alert engine checks the timeline, notifiers route the signal, and the gatekeeper controls remediation.

// ingest.paths

Docker logs enter from hosts and agents.

Tail Docker logs by default on each host or enrolled agent, then forward logs and Docker events from agents into a central LogForge host.

host: docker://worker-02 tail
agent: edge-agent-01 tail + forward
state: ingested
next: rules.match

// operator.tabs

Use cases by operator mode.

// home.lab

Catch container drift before a side project goes quiet.

Monitor NAS apps, media services, dashboards, and local automations from one browser surface.

query: containers where restart_count > 3 in 10m
result: plex-worker entered restart loop
route: gotify + email
action: restart after cooldown

// ai.agent.chat

The AI-native ingestion and control plane for Docker infrastructure.

LogForge ingests logs, Docker events, containers, incidents, deploy history, ownership, code, and docs into an AI-native infrastructure layer built for agents first. Operators chat for reports, explanations, incident investigation, and guarded remediation, while LogForge compacts live operational state into structured, source-linked context the agent can reason over. Local models connect through Ollama, and control-plane actions remain governed by policy and operator approval.

logforge://ai-agent/report traversing
operator

For all frontend services on the production machine in the last 6 months, provide an error report, compare it with the previous 6 months, and add the delta.

LogForge AI Agent

Traversing live operations graph

  • logs
  • Docker events
  • deploy windows
  • incidents
  • owners
  • code/docs
// output.summary

Frontend error report

Production frontend services, last 6 months compared with the previous 6 months.

ready
web-ui 3,482 vs 2,471 errors
+41%
checkout-frontend 1,214 vs 754 errors
+61%
admin-console 386 vs 472 errors
-18%
likely contributors

Most of the increase clusters around the February 14, 2026 auth-cache deploy and incident LF-2407, then tails off after the March 3, 2026 retry rule change.

recommended next steps

Review src/routes/session.ts, raise the checkout timeout alert threshold, and queue a guarded nginx reload playbook for operator approval.

log:error-family/auth-timeout deploy:web-ui@2026.02.14 incident:LF-2407 owner:frontend-platform
report.task error delta

Compare long-window error trends across production services and return the delta with linked evidence.

explain.task container context

Explain what a container does from metadata, logs, docs, code, deployment history, incidents, and ownership.

remediate.task guarded action

Draft commands or rule edits, then wait for operator approval anywhere LogForge policy requires it.

// rule.templates

Templates for the failures Docker operators already know.

Start from known failure modes, tune thresholds per container, then write custom rules across logs, event rates, missing signals, metrics, and Docker events.

STABILITY

Restart loop

Crash loop, restart loop, failed start.

PERFORMANCE

Resource pressure

High CPU, high memory, low disk.

LOGS

Error patterns

Error flood, OOM, database connection issues.

SECURITY

Suspicious activity

Unauthorized access and suspicious network activity.

// benchmark.compare

Logs vs action

Other tools show logs. LogForge turns them into alerts, routes, and fixes.

category others logforge
VISIBILITY ✓ log viewer ✓ real-time Docker dashboard
VISIBILITY × context split across tools ✓ logs, files, containers, and history together
ALERTING × manual search or external setup ✓ templates plus custom rules for logs, rates, absence, metrics, and Docker events
ALERTING × narrow notification paths ✓ Slack, Discord, Telegram, Gotify, Teams, Pushover, SMS, email, webhook
REMEDIATION × stops at awareness ✓ restart, stop, kill, start, or script action with cooldown and backoff
AI AGENT × isolated errors with no historical context ✓ graph-grounded reports, container explanations, and guarded remediation plans
CONTROL ✓ single-host dashboards or separate agents ✓ central LogForge host with enrolled edge agents across Docker hosts
PERFORMANCE × remote tailing, SSH polling, or noisy side channels ✓ forwarded logs and events consumed by central LogForge
PRIVACY × cloud-first log shipping ✓ self-hosted control plane for local and agent-forwarded operational data

// enterprise.mesh

One central host. Every Docker edge in view.

Businesses, platform teams, MSPs, and distributed operators can run LogForge on a central host, enroll trusted edge agents, and monitor multiple Docker machines without making the central host poll every remote Docker node.

Docker log tailing still works out of the box on each host or agent. The latest high-performance path is agent-forwarded logs and events into central LogForge.

// local.control

Self-hosted by default, cautious by design.

SELF-HOSTED

Run LogForge in your Docker environment and keep the control loop close to the host.

LOCAL DATA

Keep logs, alert rules, action results, and history in your own deployment.

DOCKER SOCKET AWARENESS

Make container actions visible and intentional instead of hiding them behind generic webhooks.

LOCAL ADMIN

Manage operators, alert rules, channels, and guarded actions from the local admin surface.

CENTRAL + EDGE

Run a central LogForge host and enroll trusted edge agents over mTLS for remote Docker nodes.

FORWARDED LOGS

Use agents to forward logs and events into central LogForge for the latest high-performance path. Docker log tailing remains the simple out-of-the-box setup on each host or agent.

// premium.waitlist

Premium for central and edge operators.

Join the waitlist for advanced central host workflows, enterprise agent management, and support options for teams that monitor Docker across multiple machines.

  • Central host visibility for enrolled Docker edges.
  • Priority planning for platform teams, MSPs, and distributed operators.
  • Premium rollout details sent as they become available.
waitlist.form premium

Open Google Form Explore Cirdan

// install.local

Install LogForge on a local or central Docker host.

Run the installer to clone or update LogForge, start the Compose stack, and open the dashboard. Start with Docker log tailing out of the box on a single host or enrolled agent, then forward remote host logs to the central deployment.

Docker Compose localhost:8444 self-hosted
terminal 
curl -fsSL https://www.logforge.dev/install.sh | sh