Resources · n8n integration

n8n Trigger nodeConfigure n8n Trigger in n8n.

The n8n Trigger node lets a workflow react to its own lifecycle. It opens the workflow when that workflow is published, when an already published version is published again, or when the instance starts. One parameter, Events, 3 boxes to tick, no more.

Try the n8n Trigger node on n8nSee the 1 parameters

Verified Trustpilot reviews · AI, automation & growth agency

Why automate

What does the n8n Trigger node actually watch?

This node is n8n keeping an eye on n8n. Put it in a workflow and that workflow wakes up on its own lifecycle: when it gets published, when a published version is published again, or when the instance hosting it starts or restarts. It watches nothing else. A colleague publishing another workflow next door leaves it asleep.

First scenario, the restart check. Tick Instance Started and the workflow opens every time the instance boots or reboots, which is the moment to run a short sanity pass: call one internal endpoint with HTTP Request, the node that calls any HTTP endpoint, then post the result to a maintenance channel with Slack. Nobody has to remember to check after a container comes back up.

Second scenario, the publication log. Tick Workflow Published and every first publication writes a line somewhere you can read later, a row in Google Sheets for instance. Teams that share one instance get a plain record of what went live and when, without asking anyone to fill in a form.

Third scenario, the change notice. Tick Published Workflow Updated and a republished workflow tells the people who depend on it, by mail through Gmail. Add an If node behind it to keep the notice for the workflows that really matter and stay quiet on the rest.

When to reach for something else: this node only opens a workflow on its own lifecycle. It does not call an API, it does not read a file, it does not watch a third-party account. Anything that starts from an outside service belongs to that service's own node, and anything that needs an HTTP call inside the run belongs to HTTP Request.

The limits are worth knowing before you build on it. The node covers 3 events, no more, and it only reports on the workflow it sits in. Its version is 1, so there is no option collection to open and nothing else to tune. In production the workflow has to be active for the node to listen at all; while you are editing, a test execution listens once and then stops.

Parameters

How do you fill the Events parameter?

The n8n Trigger node has one parameter. For each one: the node as you configure it in n8n, what the parameter changes, and our field notes.

01

Events

events

What you see in n8n

Notes & use cases

One parameter carries the whole node, and it decides which lifecycle moments open the workflow. It takes several values at once, so a single node can cover publication and restart together.

Key parameters

  • Published Workflow Updated: triggers when the workflow version is published from a published state, meaning the workflow was already published.
  • Instance Started: triggers when this n8n instance is started or re-started.
  • Workflow Published: triggers when the workflow version is published from an unpublished state.
Use cases
leave Instance Started alone on an instance you host yourself and every reboot runs your morning check. Tick the two publication events together when the workflow is the audit trail of your team.
Need help

Need help automating n8n Trigger with n8n?

A person reads every message.

FAQ

n8n Trigger node, the questions that come next

01Is the n8n Trigger node free to use?
Yes. It is a core node, shipped with n8n, so there is nothing to install and no extra cost on the n8n side. It behaves the same on n8n Cloud, the hosted offer run by n8n, and on an instance you host yourself with Docker or npm under the Community Edition and its Sustainable Use license. A workflow built on one runs on the other without changes, which matters here because the node reacts to the instance it lives on. Move the workflow to another instance and it starts reporting on that one instead. The only thing you pay for is whatever the rest of your workflow calls, which is your business, not the node's.
02What do you need to connect before it runs?
Nothing. This node has no credential and no Authentication selector, so there is no account to link, no key to paste and no permission to grant before it works. That makes it one of the fastest nodes to get going: drop it on the canvas, tick the events you care about, and the configuration is done. Two habits still matter. The workflow has to be active for the node to listen in production, otherwise it sits there and nothing opens. And while you build, the test execution arms a single listen, so you get one shot before you have to start it again. Everything else happens in the nodes you place after it.
03What are its limits?
Three things bound it. It only responds to events in its own workflow, so publishing or updating another workflow never wakes it, and it cannot be used as a central watcher over an instance full of automations. It covers 3 events and no others, which means no reaction to an execution failing, a user logging in or a credential changing. Its version is 1, with a single parameter and no option collection to open, so there is nothing hidden to tune. Plan around it: one node per workflow you want to track, and the reporting logic in the nodes that follow.
04When do you pick this node over an HTTP call?
Pick it when the thing you want to react to is the workflow itself: it was published, it was published again, or the instance came back up. Those moments have no URL to poll and no outside service to ask, so only a node inside the workflow can see them. HTTP Request answers a different question. It calls any HTTP endpoint, and it is the fallback when a dedicated node is missing an API operation, but it never opens a workflow on its own. In practice the two sit in the same run: the n8n Trigger node opens it, HTTP Request goes and fetches whatever you need to report.
05n8n or Make for this kind of monitoring?
It comes down to where the automation lives. Make is a hosted platform, with no self-hosting option and a bill that counts operations, so a workflow that fires on every restart and every publication adds to that count. n8n runs on Cloud or on your own machine, which is the whole point for a node that reports on the instance: on a self-hosted setup, the data about your workflows never leaves it. Both give you a visual canvas, and both are pleasant to build in, so the honest criteria are hosting, control over your data and the cost model rather than the editor itself.
Hack'celeration Lab

Get our weekly integration tips.

No spam. Unsubscribe anytime.

Same platform

Other docs you might need on this stack.

Browse all integrations