A trigger node is the exclusive entry point for every automated n8n
workflow—it defines when and how a workflow starts. 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. n8n
provides five core trigger types that span webhook receivers, cron‑based
schedulers, service‑native event listeners, polling checkers, and
on‑demand manual triggers.
[1]
[2]

How does the Webhook node listen for HTTP requests and trigger workflow execution?

The Webhook node exposes a unique URL that listens for incoming HTTP
requests. When an external service sends a request to that URL, n8n
fires the workflow immediately, passing the request body, headers, and
query parameters as the initial input. The node provides two URLs:
a Test URL for development and a Production
URL that activates on publish.
[4]
[6]

The node supports six HTTP methods—DELETE, GET, HEAD, PATCH, POST, and
PUT—and can be expanded to accept multiple methods simultaneously via
the “Allow Multiple HTTP Methods” setting, which creates separate output
branches per method [6].
For authentication, n8n offers four methods: Basic Auth, Header Auth,
JWT Auth, and None (public). The Path parameter supports dynamic route
segments with colon‑prefixed syntax (e.g., /:userId). Max
payload is 16 MB, adjustable via N8N_PAYLOAD_SIZE_MAX on
self‑hosted instances [4].
For production, always secure the Production URL with HMAC signature
validation, IP allowlisting, or Header Auth — see our complete
Webhook node configuration guide.

How do you configure the Schedule Trigger node with cron expressions and timezones?

The Schedule Trigger node executes workflows at fixed intervals using
two scheduling styles: interval mode (timers like every
5 minutes, every 3 hours, every day at 8:30 AM) and custom cron
mode (e.g., 0 9 * * 1-5 for weekdays at 9 AM).
You must publish the workflow for the trigger to fire automatically;
the node supports adding multiple trigger rules for different schedules.
[7]
[8]

Timezone is critical: n8n uses the workflow‑level timezone if set;
otherwise it falls back to the instance timezone. Self‑hosted instances
default to America/New York; Cloud instances attempt to
detect the owner’s timezone on signup, falling back to GMT [8].
Custom cron expressions use a six‑field syntax (seconds, minutes, hours,
day, month, weekday). After removing the seconds column, validate at
crontab.guru [9].
Variables used in schedule triggers are only evaluated when the workflow
is published; to apply a changed variable value, you must stop and
publish a new version [9].
For the complete list of available trigger intervals—Seconds, Minutes,
Hours, Days, Weeks, Months, and Custom (Cron)—see our
trigger nodes synthesis guide.

How does the Manual Trigger node start workflows on demand for testing and one-off tasks?

The Manual Trigger node starts a workflow when you click the
Execute Workflow button on the canvas. It is
configuration‑free—you add it as the first node and click to run.
Manual executions display results directly in the node output panels,
require no workflow activation, and are primarily used for building,
testing, and debugging before switching to an automated trigger.
[5]
[10]

Manual trigger workflows do not need to be published; they run
immediately on demand and are ideal for data migration scripts,
one‑time reports, and approval workflows where a human decision is
required before execution. Unlike production triggers, manual
executions do not consume your plan’s monthly execution quota on test
runs. For designing workflows that involve human approvals, combining
a Manual Trigger with the Wait node creates a powerful approval
pattern—learn more in our
error handling and retry guide.

How do App Event triggers listen for native events in services like GitHub and Google Sheets?

App Event triggers—such as the GitHub Trigger (new issue), Google Sheets
Trigger (row added), and Gmail Trigger (new email)—listen natively for
events inside a specific service. Under the hood they use either webhooks
or polling, but they handle authentication, subscription, and data
parsing automatically. When the configured event occurs, the trigger
fires the workflow and passes the event data as input.
[2]
[3]

App Event triggers are the simplest path to service‑connected automation
because they eliminate the need for manual webhook configuration. A
GitHub Trigger, for instance, creates a repository webhook automatically
through n8n’s OAuth connection—no URL copying or secret configuration
required. For services that do not offer native webhook support, n8n
falls back to polling. To understand the deep architectural differences
between webhook‑based and polling‑based triggers, see our
beginners node guide.

How do polling triggers periodically check external services for new data?

Polling triggers check external services at a fixed, configurable
interval—every minute, 5 minutes, or hour—by calling the service’s API
and comparing results against a stored checkpoint (last timestamp or
highest record ID). When new or changed data is detected, the trigger
starts the workflow and passes the fresh records as input. Polling uses
the poll() execution method internally.
[11]
[12]

Polling triggers are essential for services that lack webhook support.
They work with almost any API but introduce an inherent latency equal
to the polling interval and can generate many empty API calls. For
teams optimizing polling efficiency, the checklist includes: set the
polling interval to the minimum acceptable latency for your use case,
use a timestamp or sequential ID as the checkpoint to avoid re‑
processing old data, and monitor API rate limits if polling at high
frequency [12].
For a deep dive into checkpoint management, rate‑limit avoidance, and
batch processing patterns, see our
SplitInBatches loop and iteration guide.

How do manual testing and production execution modes differ for trigger nodes?

n8n operates in two execution modes. Manual mode runs
when you click “Execute Workflow” or “Execute step”—it displays results
in the editor, requires no activation, and is for development only.
Production mode activates automatically via trigger
nodes when the workflow is published—the activation toggle in the top
bar switches the workflow from inactive to active state.
[5]
[13]

The ActiveWorkflowManager handles the full lifecycle: on instance
startup it batch‑activates all published workflows in the database,
registers webhook routes, starts trigger listeners, and manages polling
schedules with exponential‑backoff error recovery. A workflow is
considered “active” only when it has an
activeVersionId and contains at least one trigger‑like
node [13].
For the complete production deployment workflow, see our
Docker Compose production stack guide.