The problem it covers: an active workflow that never ran produces no failed execution. An error workflow only fires when something runs and fails, so it stays quiet — after a restart that did not re-register the schedule trigger, or when someone toggles a workflow off while debugging and forgets it. The execution list looks clean and nothing has run for five days.
What it does: reads your instance through the n8n API, takes every active workflow, finds its last execution and returns the ones quiet longer than you allow. Five nodes — schedule trigger, a config node, two HTTP Request nodes, one Code node. Attach whatever you use for alerts at the end.
Setup: create an API key under Settings → n8n API, add a Header Auth credential named X-N8N-API-KEY on both HTTP nodes, then set your base URL and how many hours of silence are still normal for you.
Two limits worth knowing. It lives inside the instance it watches, so if that instance is down or its triggers never re-armed, the check does not run either — and its silence looks exactly like everything being fine. And it reads the last 250 executions, so on a busy instance a workflow that went quiet weeks ago falls out of that window.
Full disclosure, since the account name gives it away: we build Duskwatch, which runs this kind of check from outside and across several instances. The workflow above is free and MIT, and there is nothing in it that phones home — it is the honest single-instance version of the same idea.
Useful, thanks. One case it cannot see, from my own version of this.
I had 27 branches that were being skipped for weeks. They all ran. Every one produced a fresh execution on schedule, so a last-execution check would have shown them perfectly healthy. They were finishing COMPLETED and doing nothing.
So quiet-for-N-days catches the stopped workflow and is blind to the running-and-idle one, which is the harder of the two because it looks alive.
What I do now is count at the edges: the step records how many records the tool returned, so a run that processed nothing shows 0 records next to the tool instead of a green tick. I only built that last week, and it is one-sided. It proves the source handed over nothing. It still does not prove the destination did anything.
@Aghassi you’re right, and the same gap exists in Duskwatch itself. It knows three incident kinds and a run that finishes COMPLETED while doing nothing falls through every one of them.
The only signal I can think of that’s visible from outside is duration. Every execution in the API carries startedAt and stoppedAt, so you can keep a per-workflow median and flag runs that suddenly finish in a fraction of their usual time. A sync that normally takes 40 seconds and now takes 2 is probably handing over nothing. It doesn’t need payload access, which matters to us because we don’t read execution data at all.
It’s weaker than it sounds though. It catches a workflow that goes idle as a whole. Your case, 27 skipped branches inside runs that otherwise kept working, might barely move the total. Your edge counts are the better tool there.
Destination side, no idea. Haven’t found anything that proves a write happened without reading what was written.
That is the first mechanism anyone has offered me that needs no payload access at all. Everything else I have been given has to see the data: items in versus items out per stage, a historical volume baseline, counts at the edges. Yours is metadata only, which also means it fits inside the zero-access promise that another person here told me bounds his own product.
I tested it on the two runs I have. Same agent, same tool, one returned 10 records and one returned 0. The full run took 18.8 seconds and the empty one took 13.2. Only 30 percent faster, because the model call dominates the clock and the payload does not.
So I think the signal splits by where the time goes. In your case, a 40 second sync that comes back in 2, the time is data movement and the drop is obvious. In an agent run the LLM is most of the duration, so an empty run looks close to normal. Strong signal in your world, weak in mine.
On the destination side I have the same answer as you. The best framing I have heard is that when there is no reliable way to verify the final state, the honest label is “not verifiable with certainty” rather than treating a completed call as proof. I have not built that either.