Docs › Home Assistant automation monitoring with RunVouch
Home Assistant automation monitoring with RunVouch
Home Assistant automation monitoring from outside the house: an automation with a time trigger that runs a shell_command or a conversation agent keeps working until an update breaks the integration or the automation is left disabled. The logbook records it; nobody reads the logbook.
How it runs on Home Assistant automations
A rest_command at the start and end of the automation, or wrap the shell command with rv run if the script runs on the same host.
Store the key
Put the key in secrets.yaml and reference it with !secret runvouch_key.
Report the run (two HTTP calls)
# configuration.yaml
rest_command:
runvouch_start:
url: https://api.runvouch.com/v1/runs/start
method: POST
headers: {X-API-Key: !secret runvouch_key, content-type: application/json}
payload: '{"agent":"nightly-backup","source":"home-assistant"}'
runvouch_end:
url: https://api.runvouch.com/v1/runs/end
method: POST
headers: {X-API-Key: !secret runvouch_key, content-type: application/json}
payload: '{"run_id":"{{ run_id }}","status":"ok","evidence":{"backup": true}}'
# automation: call runvouch_start, store response_variable, do the work, call runvouch_end with run_idThe start call returns run_id; the end call takes status (ok or fail), optional cost and tokens, and evidence as a JSON object of booleans. Full reference on the API page.
Register the cadence and caps
rv agent nightly-report --cadence 24h --grace 30m --max-runtime 1h --evidence --cap-run-cost 2
Register the agent once, from anywhere with the key. Cadence is what turns a schedule that stopped into an alert; --evidence makes a run without evidence a failure; the caps pause the agent when it overspends.
What goes silent on Home Assistant automations
- Disabled automations and broken integrations after a core update do not notify; MISSED does.
- A shell command that exits non-zero is a warning in the log, not an alert.
What Home Assistant automations does not tell you
Home Assistant writes automation triggers to the logbook and shows the last triggered time on each automation; a persistent notification appears for some integration failures after a core update, and for nothing else. A disabled automation, a shell_command that exits non-zero (logged as a warning), or a time trigger that did not fire because the instance was restarting, produces no alert unless you build one. The reverse direction also works: the RunVouch REST sensor package shows each agent's state as an entity so you can automate on it.
What RunVouch detects
| Alert | What it means here |
|---|---|
| MISSED | cadence plus grace passed and no run started |
| FAILED | non-zero exit or a reported failure, with the stderr excerpt |
| NO_EVIDENCE | the run said ok but the file, URL or assertion you required is missing |
| STALLED | a run started and never ended within max runtime |
| RETRY_STORM | the same tool called with identical input many times in one run |
| BUDGET_RUN / BUDGET_DAY | cost cap crossed; the agent is paused until you resume it |
| DRIFT | duration or output size far off its 7-run baseline |
Set up in two minutes
- Get a free key (3 agents, no card) and store it where this page says.
- report the run (two http calls): copy the snippet above into the scheduled job.
- Register the cadence once:
rv agent nightly-report --cadence 24h --grace 30m --evidence, or let the first run create the agent and set the cadence on the dashboard. - Send one test alert:
curl -X POST https://api.runvouch.com/v1/settings/test-alert -H "X-API-Key: $RUNVOUCH_KEY". The next missed, failed or empty run reaches the same channels.
Also running no-code automation?
n8n (community node). Make (Integromat). Zapier. The full list of runtimes is on integrations, and the same agent can report from several of them: one job, one cadence, wherever it happens to run.
Need a key? Get a free key · Stuck? contact