automation-health-mcp
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@automation-health-mcpAudit all cron jobs for failures"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
automation-health-mcp
An MCP server that finds the automation which stopped working without telling anyone.
Most automation does not fail loudly. It keeps running, keeps exiting zero, keeps writing to its log — and quietly stops doing the work. The dashboard stays green. Nobody finds out until somebody asks a question about the numbers.
This server gives an LLM agent the tools to go and check.
> Audit the automation on this machine.
critical com.acme.sync scheduled job is failing (exit code 1)
critical publisher.log no output for 74h (threshold 26h)
critical api.example.com/accounts HTTP 200 but 'data' is empty —
the endpoint answers while holding nothing
warning worker.log recent errors: login_required
warning billing.py:42 unfinished logic returning a hardcoded valueWhy this exists
I audited my own stack and found six scheduled jobs that had been dead for weeks. Every one of them reported success in the way that mattered to whatever was watching:
a messaging job authenticated, received
login_required, and exited quietlya publishing integration returned
HTTP 200while holding zero connected accountsa report had been renamed
.DISABLEDduring debugging and never renamed backa budget function read its input file, ignored it, and returned the constant it was seeded with
None of these are exotic. They are the normal ways automation dies, and none of them trip a conventional "is the process running" check.
Related MCP server: Playwright Pool
What it checks
Tool | Question it answers |
| What is scheduled on this machine, and what did it exit with? |
| Which scheduled jobs are failing right now? |
| Which daily jobs have produced no output in over a day? |
| Which logs show failures in the last 24 hours? |
| Does this integration return content, or just a status code? |
| Which functions are marked TODO and still return a hardcoded number? |
| All of the above, in one prioritised report |
Two design decisions worth calling out:
Recent errors only, tail only. Scanning whole log files resurfaces failures that were fixed weeks ago and turns the report into noise you learn to ignore. Only recently-modified files are read, and only their last lines.
Payload over status code. check_endpoint takes a JSON path — data, result.accounts — and treats an empty collection there as critical. This is the check that catches a disconnected integration, which presents itself as a perfectly healthy HTTP 200.
Install
uvx --from automation-health-mcp automation-healthOr add it to your MCP client configuration:
{
"mcpServers": {
"automation-health": {
"command": "uvx",
"args": ["--from", "automation-health-mcp", "automation-health"]
}
}
}Requires Python 3.10+. macOS reads launchd; Linux reads systemd.
Use it from an agent
Audit /var/log with job prefix "com.acme." and code in ~/src/api.
Check whether https://api.example.com/v1/accounts still holds live accounts —
the JSON path is "data".Use the checks directly
The check layer has no MCP dependency, so it also works as a plain library — in a cron job, a CI step, or a health endpoint:
from automation_health import checks
findings = (
checks.failing_jobs("com.acme.")
+ checks.log_freshness("/var/log/acme", max_age_hours=26)
+ checks.recent_errors("/var/log/acme")
)
for f in findings:
print(f.severity, f.subject, f.detail)The part that actually matters
The checks are the easy half. The half that decides whether any of this works is where the findings go.
I had a monitoring script before any of this. It ran daily, correctly detected that my main plan file was eleven days stale, and wrote that finding to a log file. Nobody reads log files. I had built a smoke detector and installed it in a room I never enter.
A detector whose output nobody consumes is not a detector. It is a diary.
So route the output of audit somewhere unavoidable: a Slack channel, the top of a dashboard, a file that gets injected into your agent's context at the start of every session. Push, not pull.
The question to ask about any automated system is not "is it running?" It is:
"If this stopped working tonight, how exactly would I find out?"
Development
uv run --with pytest --with "mcp[cli]" python -m pytest tests/ -qLicence
MIT — see LICENSE.
Built by Elite Product LLC. We build and stabilise automation systems for companies: integrations, AI agents, and the reliability layer that tells you when they quietly stop working.
This server cannot be installed
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/chainwright/automation-health-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server