01 / THE ROLE
In this lab.
n8n runs as a containerised workflow application using PostgreSQL and persistent application storage. One documented use is receiving events from monitoring and backup-related systems and routing notifications to a messaging channel. The public guide explains the pattern without revealing webhook URLs or recipients.
02 / THE CONNECTIONS
Follow the flow.
A responsibility view: branches show related components, rather than physical placement or a single request path.
03 / How it works
How it works.
A workflow receives an event, extracts useful fields and selects the appropriate action. Different event producers have different payloads, so routing and transformation are explicit parts of the design. Execution history helps distinguish a source that never sent an event from a downstream delivery failure.
04 / Persistent data & recovery
Persistent data & recovery.
Recovery needs the PostgreSQL data, relevant application files and the encryption material required to use stored credentials. Restoring a workflow definition without its secure dependencies can leave a visually complete workflow that cannot perform its actions.
05 / How to check it
How to check it.
Test a safe sample through the complete route and confirm delivery at the destination. An accepted webhook, successful workflow step and delivered notification are different pieces of evidence. Review error handling and retry behaviour rather than assuming either exists.
06 / Decisions & limits
Decisions & limits.
Central routing makes integrations easier to extend but introduces another dependency in the alert path. Notification delivery must be tested independently of the monitoring platform’s ability to generate an event.