> Bron: https://neuralex.nl/en/showcase/workflows
> 210 n8n workflows as the orchestration layer of our lab: disk monitoring, pipeline monitors, security scans and backup orchestration. Including the two automations we tore down again.

Showcase · Workflow automation

# 210 workflows — and two we deliberately tore down

Automating is the easy part. The hard part is deciding **what you don't automate**, and which workflow creates more noise than it solves. Our n8n layer orchestrates the operations of our own lab: disk monitoring, pipeline monitors, security scans and backup orchestration.

[Schedule a call](/en/contact) [See the two lessons](#lessen)

210

workflows in production

2

instances: running + building

1

append-only event store

2

automations rolled back

Architecture

## Trigger → assessment → action → log

Every workflow follows the same shape. There is a cause, there is an explicit threshold that decides whether anything should happen, there is at most one action — and everything lands in the append-only event store.

Two lessons from our own shop

## Which automation you should not build

Two things we got wrong ourselves and then rebuilt: a monitor that matched on an imprecise container name, and a workflow that restarted a healthy container every 30 minutes.

### What we built first

1.  Monitor matches the container name on part of the string
2.  The actual Compose name differs from the name in the config
3.  Alert: "container offline" — while the container is simply running
4.  A separate workflow restarts a healthy container every 30 minutes
5.  Noise wins: you start ignoring alerts because they are usually nonsense

### What is in place now

1.  Match on the exact Compose name, not a substring
2.  A manifest with the actual container names as the source
3.  An alert means something again, because it no longer fires by itself
4.  Restart on a real health failure, not on a clock
5.  Every run lands in the event store and can be read back

Tech in detail

## A workflow isn't finished until you can read it back

### Running and building separated

The production instance runs natively under systemd and executes the 210 workflows. Building and trying things out happens on a separate Docker instance, so tinkering with a flow never touches the automation that is running.

### Triggers: cron, webhook, event

Some workflows run on a clock, others react to an incoming webhook or to an event from the event store. We choose the trigger per task — not "every five minutes" by default.

### Thresholds before actions

Disk Alert volume2 checks the disk every hour, warns via Telegram from 80% and only prunes Docker above 90%. The action sits behind a threshold, the warning goes to a human first.

### Monitoring without intervening

The Stamboom Pipeline Monitor is deliberately monitor-only: it reads out the status and reports, but restarts nothing. The Stamboom PG Watchdog guards the database side of the same pipeline.

### Every run readable afterwards

Workflows write to an append-only event store. What a flow saw, when it ran and what it decided stays on record — that is the difference between "something went wrong" and "this is where it went wrong".

### Operations as a workflow

Security scans and backup orchestration run as ordinary flows in the same environment. One place where you can see what happens automatically, instead of scripts scattered across a handful of machines.

Built with n8nsystemdTelegramWebhooksCronEvent storeREST API

From production

## The chain of a single workflow, drawn out

A clean rendering of the Disk Alert workflow as it runs every hour: trigger, measurement, split on the threshold value, and both branches ending in the same event store. On the right the most recent runs; at the bottom the automation we rolled back.

![Workflow orchestration: the Disk Alert workflow with trigger, threshold split, prune, Telegram alert and event store](/img/n8n-workflows.svg)

Orchestration

## Want to know which of your processes deserve automation?

We prefer to start by cutting rather than building: which tasks really run on a clock, which belong on an event, and which are better left alone. Only then the flows.

[Schedule a call](/en/contact) [Our approach](/en/aanpak)

---
Volledige (opgemaakte) versie: https://neuralex.nl/en/showcase/workflows