Uptime Kuma → n8n → Slack Alert Workflow

This n8n workflow receives status-change webhooks from Uptime Kuma and posts formatted alerts directly to Slack. When a monitored service goes down, your team gets an immediate red alert with full context. When it recovers, they get a clear green recovery notice — all without any manual polling or additional SaaS dependencies.

How It Works

Uptime Kuma is a powerful, self-hosted monitoring tool that continuously checks the availability of your services — including websites, REST APIs, DNS records, TCP ports, and more. Whenever a monitored service changes state (from UP to DOWN, or from DOWN back to UP), Uptime Kuma fires a JSON payload to a configured webhook URL.

This n8n workflow listens on that webhook endpoint around the clock. When a payload arrives, the workflow parses the raw data into clean, structured fields, determines whether the event represents a DOWN or UP transition, and sends a color-coded Slack message containing the service name, target host, timestamp, and a human-readable summary of the event.

The end result is real-time Slack alerting for every service state change — with no manual polling, no missed incidents, and no third-party SaaS dependency beyond Slack itself. It’s a lightweight but highly effective addition to any self-hosted infrastructure monitoring stack.

Workflow Flow

The workflow follows a simple, reliable branching pattern:

Webhook → Code (parse payload) → IF condition
                                    ├── True (DOWN)  → Slack: red alert
                                    └── False (UP)   → Slack: green recovery

Node Reference

1. Webhook (Trigger)

This is the entry point of the workflow. It listens for incoming POST requests sent by Uptime Kuma whenever a monitor changes state.

• Endpoint: POST /webhook/Anthemnetworkstatus
• Expected payload: A JSON object containing body.heartbeat (status, ping, time, message) and body.monitor (name, hostname, URL, type).

Configure this webhook URL in Uptime Kuma under the notification settings for each monitor you want to receive alerts for.

2. Code (JavaScript — Payload Parser)

This node takes the raw Uptime Kuma webhook payload and transforms it into clean, structured fields that downstream nodes can reliably consume.

Input fields read:

• body.heartbeat — contains status, ping, time, and msg
• body.monitor — contains name, hostname, url, and type

Output fields created:

• isDown — boolean, set to true when heartbeat.status === 0 (Uptime Kuma uses 0 for DOWN and 1 for UP)
• name — the monitor’s display name
• hostnameOrURL — the monitor’s hostname or URL, whichever is available
• time — the heartbeat timestamp, with a fallback to the current time if the field is missing
• status — a human-friendly string: either "Down" or "Up"
• msg — a human-readable summary of the state change event

The original heartbeat and monitor objects are also passed through for reference or future use.

3. IF (Condition — Route by Status)

This node evaluates the isDown field and routes the execution into one of two branches:

• True (service is DOWN) → routes to the DOWN alert node
• False (service is UP) → routes to the UP recovery alert node

The condition evaluates {{ $json.isDown }}.

4. DOWN Alert (Slack — HTTP Request)

This node fires whenever a monitored service goes down. It sends a POST request to a Slack Incoming Webhook URL with a red-themed alert message designed to grab immediate attention.

• Header: 🚨 Service is DOWN
• Color: #e01e5a (red)
• Fields included: Service name, Status, Target (hostname or URL), Time
• Details: The raw heartbeat message and the formatted msg summary

5. UP Alert (Slack — HTTP Request)

This node fires when a previously downed service recovers. It sends a POST request to the same Slack Incoming Webhook URL with a green-themed recovery message to confirm the service is healthy again.

• Header: ✅ Service is UP
• Color: #2eb886 (green)
• Fields included: Service name, Status, Target (hostname or URL), Time
• Details: The formatted msg summary

Setup Notes

• In Uptime Kuma, add a notification of type Webhook and point it to the n8n webhook URL shown above. Apply this notification to every monitor you want covered.
• In n8n, update both Slack HTTP Request nodes with your actual Slack Incoming Webhook URL. You can use the same webhook URL for both DOWN and UP alerts, or route them to separate channels for better visibility.
• Test the full workflow by temporarily pausing or toggling a monitor in Uptime Kuma. Confirm that both the DOWN and UP alerts appear correctly formatted in your Slack channel before relying on it in production.

Goal

Set up Caddy as the public-facing reverse proxy for a Dockerized Mailu mail server, with both services sharing the same Sectigo wildcard TLS certificate. The end result:

• https://my.richardapplegate.io/webmail and /admin are accessible through Caddy on public port 443.
• Mailu’s front container serves HTTPS internally on port 443 within the Docker network.
• SMTP, IMAP, and POP3 ports (465, 993, 995, 587) use the same Sectigo wildcard certificate.
• There are no port conflicts and no redirect loops.

How It Works

Running Caddy in front of Mailu introduces a dual-TLS architecture. Caddy terminates TLS for web traffic on public port 443 and then proxies requests to Mailu’s front container over an internal HTTPS connection. Mailu also needs its own copy of the certificate because its mail services (SMTP on port 465, IMAP on port 993, POP3 on port 995) terminate TLS directly — Caddy is not involved in mail protocol traffic.

The key challenge is avoiding redirect loops. When Mailu is configured with TLS_FLAVOR=cert, its front container enforces HTTPS on all connections. If Caddy proxies to Mailu over plain HTTP (http://front:80), Mailu responds with a redirect to HTTPS, which Caddy forwards to the client, which sends the request back to Caddy, creating an infinite loop. The fix is to have Caddy proxy to https://front:443 instead, so Mailu sees an HTTPS connection and serves the content directly.

Both Caddy and Mailu mount the same certificate files from a shared host path. This ensures that the certificate presented on port 443 (web) matches the certificate presented on ports 465, 993, and 995 (mail), which is important for clients that validate hostnames across protocols.

Configuration

1. Certificates on the Host

You need two files from your Sectigo wildcard certificate: the full chain and the private key. Store them in a stable host path that both Caddy and Mailu can mount as read-only volumes:

• /mnt/volumes/certs/fullchain.pem
• /mnt/volumes/certs/privkey.pem

Before proceeding, verify that the certificate and private key match by comparing their modulus hashes:

openssl x509 -noout -modulus -in fullchain.pem | openssl md5
openssl pkey -noout -modulus -in privkey.pem  | openssl md5

Both commands should output the same MD5 hash. If they do not match, the certificate and key are from different pairs and TLS will fail.

2. Caddy Docker Compose

Caddy publishes the public HTTP and HTTPS ports and mounts the certificate directory as read-only:

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    networks:
      - caddy
    ports:
      - "80:80"
      - "443:443/tcp"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./data:/data
      - ./config:/config
      - /mnt/volumes/certs:/certs:ro
networks:
  caddy:
    external: true

The caddy network is defined as external so that other compose stacks (including Mailu) can join it.

3. Mailu Environment Variables (mailu.env)

These are the settings that must be correct for this setup to work:

DOMAIN=richardapplegate.io
HOSTNAMES=my,mail

PORTS=25,465,587,993,995,4190

TLS_FLAVOR=cert
TLS_CERT_FILENAME=fullchain.pem
TLS_KEYPAIR_FILENAME=privkey.pem

WEB_ADMIN=/admin
WEB_WEBMAIL=/webmail
WEBSITE=https://my.richardapplegate.io

Important notes:

• DOMAIN is the apex domain (richardapplegate.io), not a subdomain.
• HOSTNAMES contains labels only (my,mail) — do not include dots or the full domain.
• TLS_FLAVOR must be cert (not certs — this is a common mistake).
• Do not include ports 80 or 443 in the PORTS list. Caddy owns those ports publicly. Including them here will cause a port conflict.

4. Mailu Docker Compose — Networking and Certificate Mounts

4.1 Attach the front container to both networks

Mailu’s front container needs to be on two networks: the internal Mailu network (so it can communicate with the SMTP, IMAP, and other backend containers) and the external Caddy network (so Caddy can reach it for reverse proxying):

services:
  front:
    networks:
      - mailu
      - caddy

4.2 Mount the certificates into the containers that need them

At minimum, the front, smtp, and imap containers need the certificate files. The mount paths must match the filenames specified in TLS_CERT_FILENAME and TLS_KEYPAIR_FILENAME:

services:
  front:
    volumes:
      - /mnt/volumes/certs/fullchain.pem:/certs/fullchain.pem:ro
      - /mnt/volumes/certs/privkey.pem:/certs/privkey.pem:ro

  smtp:
    volumes:
      - /mnt/volumes/certs/fullchain.pem:/certs/fullchain.pem:ro
      - /mnt/volumes/certs/privkey.pem:/certs/privkey.pem:ro

  imap:
    volumes:
      - /mnt/volumes/certs/fullchain.pem:/certs/fullchain.pem:ro
      - /mnt/volumes/certs/privkey.pem:/certs/privkey.pem:ro

5. Caddyfile

Caddy terminates TLS for incoming web traffic and proxies to Mailu’s front container over internal HTTPS. This is the critical part — proxying to https://front:443 instead of http://front:80 is what prevents redirect loops:

my.richardapplegate.io {
  tls /certs/fullchain.pem /certs/privkey.pem

  # Optional: redirect the root path to webmail
  @root path /
  redir @root /webmail 302

  reverse_proxy https://front:443 {
    transport http {
      tls_server_name my.richardapplegate.io
      # Uncomment only if you encounter certificate chain issues:
      # tls_insecure_skip_verify
    }

    header_up Host {host}
    header_up X-Forwarded-Proto {scheme}
    header_up X-Forwarded-Host  {host}
    header_up X-Forwarded-For   {remote_host}
  }
}

Why proxy to HTTPS upstream? Because TLS_FLAVOR=cert tells Mailu’s front container to enforce HTTPS on all connections. If Caddy connects over plain HTTP, Mailu responds with a 301 redirect to HTTPS. The client follows the redirect back to Caddy, Caddy proxies over HTTP again, and the cycle repeats indefinitely. Connecting to https://front:443 avoids this entirely.

6. Restart Order

After making configuration changes, restart the services in this order. Mailu must come up first so that its front container is available when Caddy tries to proxy to it.

6.1 Restart Mailu

Use --force-recreate to ensure that environment variable and volume mount changes take effect:

cd /mnt/volumes/SamsungSSD970EVOPlus2TB/mailu
docker compose down
docker compose up -d --force-recreate

6.2 Reload Caddy

Reload the Caddyfile without restarting the container:

docker exec caddy caddy reload --config /etc/caddy/Caddyfile

7. Verification Tests

Run the following commands to confirm that every service is presenting the correct Sectigo wildcard certificate. All four tests should show CN=*.richardapplegate.io with a Sectigo issuer.

7.1 Web certificate (public port 443 via Caddy)

openssl s_client -connect my.richardapplegate.io:443 -servername my.richardapplegate.io </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates

7.2 Mailu front certificate (internal, from inside the Caddy container)

docker exec caddy sh -lc \
'openssl s_client -connect front:443 -servername my.richardapplegate.io </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates'

7.3 SMTP TLS certificate (port 465)

openssl s_client -connect my.richardapplegate.io:465 -servername my.richardapplegate.io </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates

7.4 IMAP TLS certificate (port 993)

openssl s_client -connect my.richardapplegate.io:993 -servername my.richardapplegate.io </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates

All four commands should return the same certificate with CN=*.richardapplegate.io and a Sectigo issuer. If any test shows a different certificate or a self-signed certificate, check that the correct files are mounted into the corresponding container.

If you are running ERPNext v15 and want real-time Slack notifications whenever stock movements occur, this step-by-step guide shows you exactly how to set up webhook-based alerts for Material Issues, Material Transfers, and Purchase Receipts. You will also learn how to avoid the common Jinja templating error that catches most people off guard during setup.

This method uses ERPNext’s built-in Webhook DocType paired with Slack Incoming Webhooks. No custom app, third-party plugin, or server script is required — just a few minutes of configuration inside your ERPNext instance.

How It Works

ERPNext includes a built-in Webhook DocType that fires HTTP POST requests whenever a document is created, submitted, updated, or deleted. In this setup, you configure webhooks that trigger on the on_submit event for stock-related documents. When a user submits a Stock Entry or Purchase Receipt, ERPNext renders a Jinja template into a JSON payload and sends it as a POST request to a Slack Incoming Webhook URL. Slack then displays a neatly formatted message in your chosen channel, including the stock entry type, item details, quantities, and warehouse locations.

There is one critical gotcha you need to understand before writing your Jinja templates. In ERPNext’s webhook context, the doc object behaves like a Python dictionary rather than a Frappe document object. This means that if you write doc.items in your Jinja template to access line items, Python interprets it as a call to the dictionary’s built-in .items() method — not as the child table field named “items.” The result is the error TypeError: 'builtin_function_or_method' object is not iterable, and your webhook silently fails. The fix is straightforward: use doc.get('items', []) instead, which safely retrieves the child table without any conflict.

You will also need two separate webhooks because Material Issue and Material Transfer are types within the Stock Entry DocType, while Purchase Receipt is an entirely separate DocType with its own data structure.

Step 1 — Create a Slack Incoming Webhook

1. Go to https://api.slack.com/apps.
2. Create a new Slack app or open an existing one.
3. Under Features, enable Incoming Webhooks.
4. Click Add New Webhook to Workspace and select the channel where you want stock alerts to appear.
5. Copy the generated Webhook URL — you will need it in the next steps.

Security note: Treat this URL like a password. Anyone who possesses it can post messages to your Slack channel. Never commit it to version control or share it in a public forum.

Step 2 — Create the Stock Entry Webhook (Material Issue + Material Transfer)

In ERPNext, navigate to the search bar, type Webhook, and click New to open a blank webhook form.

Webhook Settings

Condition

Add a condition to ensure this webhook only fires for Material Issues and Material Transfers, and not for every Stock Entry type in the system:

doc.stock_entry_type in ("Material Issue", "Material Transfer")

Without this condition, you will receive Slack alerts for every stock entry type — manufacture entries, repack entries, material receipts, and more — which quickly creates notification fatigue and makes alerts meaningless.

Request Header

Add one header row so Slack correctly interprets the incoming data:

JSON Payload

Paste the following template into the Request Body field. Note that this template uses doc.get() throughout to avoid the doc.items dictionary conflict described earlier:

{
  "text": "📦 *Stock Entry Submitted*\n*Type:* {{ doc.get('stock_entry_type', '—') }}\n*ID:* {{ doc.get('name', '—') }}\n*Company:* {{ doc.get('company', '—') }}\n*Posting:* {{ doc.get('posting_date', '—') }} {{ doc.get('posting_time', '') }}\n*From WH:* {{ doc.get('from_warehouse') or '—' }}\n*To WH:* {{ doc.get('to_warehouse') or '—' }}\n\n*Items:*\n{% for i in doc.get('items', []) %}• {{ i.get('item_code', '—') }} — Qty: {{ i.get('qty', 0) }} {{ i.get('uom', '') }} ({{ i.get('s_warehouse') or i.get('t_warehouse') or '—' }})\n{% endfor %}"
}

Step 3 — Create a Separate Webhook for Purchase Receipt

Purchase Receipt is a distinct DocType in ERPNext — it is not a subtype of Stock Entry. You cannot handle it by adding another condition to the Stock Entry webhook. A second, dedicated webhook is required.

Webhook Settings

Add the same Content-Type: application/json header as before. No condition is necessary unless you want to filter alerts by a specific supplier, company, or warehouse.

JSON Payload

{
  "text": "🧾 *Purchase Receipt Submitted*\n*ID:* {{ doc.get('name', '—') }}\n*Supplier:* {{ doc.get('supplier', '—') }}\n*Company:* {{ doc.get('company', '—') }}\n*Posting:* {{ doc.get('posting_date', '—') }} {{ doc.get('posting_time', '') }}\n\n*Items Received:*\n{% for i in doc.get('items', []) %}• {{ i.get('item_code', '—') }} — Qty: {{ i.get('qty', 0) }} {{ i.get('uom', '') }} ({{ i.get('warehouse') or '—' }})\n{% endfor %}"
}

Step 4 — Test the Webhooks

Run a quick test for each document type to confirm that Slack messages are delivered correctly and contain the expected information:

1. Create and submit a Material Transfer Stock Entry. Check your Slack channel for the alert and verify the item details are correct.
2. Create and submit a Material Issue Stock Entry. Confirm the alert appears and the source warehouse is populated.
3. Create and submit a Purchase Receipt. Confirm it triggers the second webhook and displays the supplier and received items.

Troubleshooting

If no messages appear in Slack, check the ERPNext backend logs for errors. Look specifically for Jinja rendering errors or HTTP request failures. If you are running ERPNext in Docker, use one of the following commands:

docker compose logs -f backend

Or from inside the bench container:

bench --site yoursite tail

The most common causes of failure are an incorrect or expired Slack webhook URL, a malformed JSON payload (such as unescaped newlines or missing brackets), and Jinja template errors caused by using doc.items instead of doc.get('items', []).

Optional — Add a Clickable Link to the ERP Record

You can make your Slack alerts even more actionable by including a direct link to the submitted document. Add the following line inside the text field of your JSON payload, replacing erp.yourdomain.com with your actual ERPNext domain:

For Stock Entries:

https://erp.yourdomain.com/app/stock-entry/{{ doc.get('name') }}

For Purchase Receipts:

https://erp.yourdomain.com/app/purchase-receipt/{{ doc.get('name') }}

Slack automatically converts plain URLs into clickable hyperlinks, so no additional Slack Block Kit formatting is needed. Team members can jump directly from the Slack alert to the relevant ERPNext record with a single click.

Summary

You now have automatic, real-time Slack alerts for Material Issues, Material Transfers, and Purchase Receipts — all triggered on submission and formatted with item-level detail. Here are the key points to remember as you manage and expand these webhooks:

• Always use doc.get('field') instead of doc.field in ERPNext webhook Jinja templates. This prevents the doc.items conflict with Python’s built-in dictionary method and eliminates the most common webhook error.
• Material Issue and Material Transfer are subtypes within the Stock Entry DocType — use a condition filter to target only those types and avoid notification noise.
• Purchase Receipt is a separate DocType entirely and requires its own dedicated webhook configuration.
• Treat your Slack webhook URL as a sensitive credential — store it securely and never expose it in public repositories or documentation.
• Add clickable ERPNext record links to your Slack messages to help your team act on alerts quickly without searching for the document manually.