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.