With the n8n API, How do know if a workflow is published and OK?

Questions
,
1

I found some answers about testing if a workflow is running. But I’m interested in if it is published & OK (like the green bullet next to it in the workflow editor view).

Describe the problem/error/question

Running n8n locally on laptop.
CONTEXT: Created a workflow that is triggered / ~10 minutes. Checks my emails, selects some and summarizes them, then submits to a RocketChat channel.
Unfortunately, many errors happen, which “unpublish” it (e.g.: mail provider error, LLM errors, laptop lid closed → n8n sleeps, etc).
Thus, I’ve created a secondary workflow that restarts the primary:

  • on any error (nodes in primary raise errors)
  • on n8n start (n8n container starts at boot)

But I still get cases where the primary workflow stops. Wanting to add a 3rd case:

  • a trigger every 1h that checks if the workflow is “down” and, if so, restarts it.

When I use the API node to retrieve the primary workflow, I can “workflowPublishHistory” or “active”. Unfortunately, they are both true/activated even if the workflow is in error (red bullet in editor’s view).
Due to my particular setup:

  • I cannot just check if my primary workflow is published
  • I cannot just check if it is running, like in the posts I found here, since my workflow can just be “sleeping” in-between two 10 min triggers.

So my question: How do I get the same information as is underlying the display of the red/green/yellow bullet next to a workflow in editor mode, using the n8n API node?

Information on your n8n setup

  • n8n version: 2.45.7
  • Database (default: SQLite): default
  • n8n EXECUTIONS_PROCESS setting (default: own, main): own, main
  • Running n8n via (Docker, npm, n8n cloud, desktop app): running in home made incus container that starts npx n8n
  • Operating system: Debian 14 guest / LMDE 7 Host
2

Checking the `active` flag via the n8n API only tells you if the workflow is toggled on, which is why it remains true even when runtime errors trigger a red bullet. To programmatically check health, you should query the `/executions` endpoint filtered by `status=error` alongside your workflow status check to verify if the last run succeeded. Let me know what database backend you are using for your self-hosted setup and I can outline the exact API call sequence right here.

3

Hey @liar666 Welcome to the commnuity,
The n8n API node’s Workflow Get doesn’t expose the same status as that dot in 2.45.7. The editor combines trigger publication status with draft changes and configuration issues, so active=true doesn’t guarantee a green dot.

With the default publication service enabled, the editor uses GET /rest/workflows/<id>/publication-status. Its response has data.status (published, partial, failed, in_progress or not_published) and data.triggers with activation errors. You can inspect it in your browser while logged in. It’s an internal session-authenticated route, so your n8n API key won’t work there. Yellow can just mean unpublished edits, and publication status doesn’t guarantee the next email/LLM execution will succeed. What does the red dot’s tooltip say when it stops?

4

The workflow object from the API has an active flag, so check that on your ten minute run and reactivate if it’s false. Active only tells you it’s switched on though, not that it’s healthy. Pulling the latest executions and checking for a recent success is a better test. A laptop that sleeps will keep biting you too.