Making It Real-Time: Triggers and Webhooks
Explore how to transform manual workflows into autonomous, event-driven services in n8n. This lesson covers the essentials of trigger nodes, compares polling and webhook models, and demonstrates setting up a GitHub trigger for real-time issue tracking.
In our previous lesson, we successfully built the MVP of our GitHub Issue Triage Agent. We have a functional, three-node workflow that can fetch issues and post a notification to Slack. This is a significant first step, but the agent still relies on a manual command from Alex to run. The true power of automation lies in autonomy.
The goal of this lesson is to elevate our MVP from a simple, on-demand script into a fully autonomous, event-driven service. To do this, we will replace the manual trigger with a GitHub trigger. This change will allow our workflow to execute automatically and in real time, the moment a new issue is created in our repository.
An introduction to triggers
An automated service is only as good as its ability to start reliably. In n8n, the component responsible for this is the trigger node. A trigger node is the exclusive entry point for any automated workflow execution. You can think of it as an event listener in an application or the entry point of a service that waits for an incoming request.
Trigger nodes are visually distinct on the canvas: they have an output connector but no input connector and are marked with an orange lightning bolt icon. A key rule to remember is that a workflow must be active for its triggers to function automatically.
Every workflow that runs automatically must begin with a trigger node. While a workflow can technically contain multiple trigger nodes, it’s a key concept to understand that only one trigger can cause any single execution. The trigger that receives the event is the one that starts the workflow run.
Polling vs. webhooks
There are two primary mechanisms a trigger can use to learn about an event from an external service. It can either repeatedly ask for updates or it can be told about them directly. Let’s explore these two models.
The polling model
Polling triggers are nodes that check for new data on a set schedule. The developer-focused analogy is this: a polling trigger is like a script running a GET request in a cron job every minute to see if anything has changed. It is a “pull” model of data retrieval.
