7.5
/ 10
1 evaluations
2.4k Downloads
Overview
Provides lightweight operational monitoring of self-hosted n8n instances running in Docker by checking container status, recent logs, health, and resource usage via CLI commands.
Key Advantages
1.Simple, focused monitoring for n8n containers without extra infrastructure
2.Uses standard Docker CLI commands that are widely available in containerized environments
3.Covers key operational signals: status, logs, health status, CPU and memory usage
4.Non-intrusive and read-only (no container restarts or destructive actions)
5.Markdown-formatted outputs with simple tables and clear status presentation
Use Cases
- Quickly checking if a self-hosted n8n instance is up and running in Docker
- Triage when n8n workflows fail or behave unexpectedly by viewing recent logs
- Routine health checks during deployments or configuration changes to n8n
- Monitoring CPU and memory usage of the n8n container during load tests or spikes
- Providing operators with a simple, scriptable status snapshot for dashboards or reports
Evaluation Scores
7.5
/ 10
Reliability
7.0
Functionality
7.5
Usability
7.5
Safety
7.5
Performance
9.0
Compatibility
6.5
Based on 1 evaluation · Latest: 3/19/2026
Download Trend
Loading...
Evaluation History (1)
7.5/103/19/2026▼
OS: linux-arm64LLM: anthropic/claude-haiku-4.5
**Quick judgement**
A focused, lightweight monitoring skill for self-hosted n8n instances running in Docker. It is well-suited for operators who need fast insights into container status, recent logs, health, and CPU/memory usage without deploying a full monitoring stack.
**What it does well**
- Uses standard Docker commands (`docker ps`, `docker logs`, `docker inspect`, `docker stats`) to gather operational data.
- Read-only behavior (no restarts or mutations), which reduces operational risk.
- Outputs in Markdown with simple tables and clear status indicators, making it easy to scan.
- Good fit for local/server environments where the assistant has Docker CLI access and n8n runs in a container.
**Key limitations & risks**
- Assumes Docker is installed, accessible from the runtime, and that the n8n container is named `n8n`; different naming or orchestration (e.g., Docker Compose with other names, Kubernetes) will break or reduce usefulness.
- `docker ps | grep n8n` can be brittle if multiple containers match the pattern or if the name differs.
- Log access (`docker logs --tail 50 n8n`) may expose sensitive data present in n8n logs (e.g., workflow payloads, tokens) to the assistant or any consumers of the output.
- Depends on the container having a defined healthcheck for meaningful health status via `docker inspect`.
**Recommended scenarios**
- You run a **single or small number of n8n containers via Docker** on a host where the assistant can execute Docker commands.
- You want a **fast operational snapshot** (up/down, health, logs, CPU/memory) for manual troubleshooting or periodic checks.
- Environments where you **control data sensitivity** and are comfortable exposing n8n logs and resource stats to this monitoring flow.
**Less suitable for**
- Kubernetes, Swarm, or more complex orchestrated environments where Docker CLI monitoring is insufficient.
- Highly regulated or sensitive environments where log contents may contain confidential data and must be tightly controlled.
- Advanced observability use cases requiring metrics time series, alerting, or historical analysis beyond simple snapshots.
Comments (0)
No comments yet. Be the first!