N8N

N8N + Webhooks: Build Event-Driven Automations That Replace Your Cron Jobs

Michael Soto

30 Dec 2025 • 3 min read

Cron jobs work until they don't. You set up a script to run every five minutes, checking for new orders or syncing data between systems. Then one day it fails silently. Or it runs twice. Or the server reboots and nobody remembers to restart the cron daemon.

Event-driven automations solve this differently. Instead of polling on a schedule, your systems push events when something actually happens. N8N catches those events via webhooks and triggers workflows instantly.

Why Webhooks Beat Polling

The difference matters for several reasons:

Immediate response: A webhook fires the moment an event occurs. No waiting for the next cron interval.

Reduced load: Polling hammers your APIs constantly, even when nothing changed. Webhooks only fire when there's actual work to do.

Guaranteed delivery: Most webhook systems include retry logic. If your endpoint is down, they'll try again. Cron jobs just fail.

Audit trail: Every webhook request comes with a timestamp and payload. You know exactly what triggered what, and when.

Setting Up Webhook Triggers in N8N

N8N's webhook node creates an endpoint you can point external services at. Here's how to set one up:

Create a new workflow
Add a "Webhook" node as your trigger
Choose your HTTP method (POST for most cases)
Copy the webhook URL N8N generates

Your webhook URL looks like this:

https://your-n8n-instance.com/webhook/abc123-unique-id

Configure your external service to POST to this URL. When it does, N8N receives the payload and kicks off your workflow.

Building a Practical Workflow

Let's build something real: a workflow that receives GitHub webhook events and posts deployment notifications to Slack.

Node 1: Webhook Trigger

Set the webhook to accept POST requests. GitHub sends JSON payloads, so N8N parses them automatically.

Node 2: IF Condition

Filter for deployment events only:

// Check if this is a deployment event
{{$json.action}} === 'created' && {{$json.deployment}} !== undefined

Node 3: Slack Message

Send a formatted notification:

{
  "channel": "#deployments",
  "text": "🚀 Deployment started",
  "blocks": [
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": "*{{$json.repository.full_name}}*\nEnvironment: {{$json.deployment.environment}}\nTriggered by: {{$json.sender.login}}"
      }
    }
  ]
}

This workflow replaces what would otherwise require a custom script, a cron job to check deployment status, and manual notification logic.

Error Handling That Actually Works

Production workflows need to handle failures gracefully. N8N provides several mechanisms:

Retry on failure: Configure nodes to retry automatically. Set the retry count and delay between attempts.

Error workflows: Create a separate workflow that triggers when your main workflow fails. Use it to send alerts or log errors.

// In your error workflow, access failure details:
{
  "workflow_name": "{{$workflow.name}}",
  "error_message": "{{$json.error.message}}",
  "failed_node": "{{$json.error.node}}",
  "timestamp": "{{$now}}"
}

Dead letter queues: For critical workflows, add a final node that catches any unhandled errors and stores them for manual review.

HTTP Request Node for Outbound Calls

Webhooks handle incoming events. The HTTP Request node handles outbound calls when you need to fetch data or trigger external APIs.

Common patterns:

Authentication: Store API keys in N8N credentials. Reference them in your HTTP nodes without exposing secrets in workflow definitions.

Pagination: Use the loop functionality to handle paginated APIs. Fetch page 1, check for more pages, repeat.

Rate limiting: Add a Wait node between API calls to respect rate limits. Better to slow down than get blocked.

// Example: Fetch data with bearer token
{
  "method": "GET",
  "url": "https://api.example.com/data",
  "headers": {
    "Authorization": "Bearer {{$credentials.apiKey}}"
  }
}

Self-Hosted Deployment Patterns

Running N8N on your own infrastructure gives you control over data, performance, and cost. A few deployment tips:

Use a reverse proxy: Put Nginx or Caddy in front of N8N. Handle SSL termination there, not in the application.

Separate the database: N8N stores workflow definitions and execution history. Use external PostgreSQL for production workloads. SQLite works for testing but doesn't scale.

Queue mode for scale: For high-volume webhook traffic, enable queue mode. N8N uses Redis to distribute work across multiple worker processes.

Environment variables for config:

N8N_PROTOCOL=https
N8N_HOST=n8n.yourcompany.com
WEBHOOK_URL=https://n8n.yourcompany.com/
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=your-postgres-host

When to Keep Cron Jobs

Webhooks aren't always the answer. Some scenarios still call for scheduled execution:

Batch processing that runs daily regardless of events
Systems that don't support webhooks
Aggregation jobs that collect data from multiple sources

N8N handles these too. The Schedule Trigger node replaces cron with a visual interface and built-in execution logging.

Deploy on Elestio

Setting up N8N with proper SSL, database configuration, and queue mode takes time. Elestio handles the infrastructure so you can focus on building workflows.

Elestio deploys N8N with PostgreSQL, automatic backups, and SSL certificates configured out of the box. Scale up when your webhook volume grows.

Ready to replace fragile cron scripts with event-driven workflows? Deploy N8N on Elestio and start building automations that respond in real-time.

Thanks for reading!