This one is our own infrastructure, not a client project. It is small, but it shows how we think about automations that must not lose data.
The situation
We run several websites, and each has a contact form. Every message is a potential client or a user with a problem, so two things matter: we must hear about it quickly, and we must never lose it.
The classic small-business setup is a form that sends an email. Then someone checks the inbox, copies the details into a CRM or spreadsheet, sends a confirmation and tries to remember to follow up. It is slow, and every step is a place where a message can be forgotten.
What we built
The first version was built for a single website. The form posted to an n8n workflow that sent a Telegram notification, so the inquiry was seen within seconds, stored the inquiry in a simple CRM and sent the sender a confirmation email.
Over time all our websites were connected to the same self-hosted n8n instance. Each forwards its submissions there, and n8n notifies us in Telegram. One place to change the logic, one place to look when something goes wrong.
That design had a weakness we did not see at first: n8n was the only copy. The website handed the message over and forgot it. If n8n was down or restarting at that moment, the message was gone, and nobody would ever know it had existed.
So we added a fallback in each website's own server code:
- When a form is submitted, the website first writes the message to a log file on its own server, marked as received.
- Only then does it forward the message to n8n.
- It records the outcome: delivered, or failed with the reason.
A received entry without a delivered entry is exactly a message that never reached us. A simple command on the server lists those, so after an outage we can see what was missed.
How it works day to day
Normally nothing changes: a message arrives in Telegram seconds after it is sent. Uptime monitoring watches the n8n instance, and an alert is the signal to check the log for undelivered messages instead of guessing.
Two behaviour choices were deliberate. If the local copy succeeded but forwarding failed, the visitor is still told the message was sent, because it was not lost, and an error would only make them retype it. And because the log holds names, email addresses and message text, it is designed to be kept only for a limited period and then deleted by a scheduled clean-up. A safety net for personal data should not become an archive of it.
The fallback switches on per site once the server provides a storage location for it; until then the site behaves exactly as before, so rolling it out could not break a working form.
What we learned
A working automation can still be fragile. A flow that simply works for a long time is exactly where a single point of failure goes unnoticed. The question to ask of any automation is not "does it work?" but "what happens to the data while it does not?"
Write first, forward second. Saving a message before handing it on means a failure anywhere downstream still leaves a record. Doing it the other way round only records what already succeeded.
The fallback must not become a new failure. Nothing in the logging code is allowed to break the submission. If writing the copy fails, the error goes to the server log and the form works as normal. Field lengths are limited so a flood of submissions cannot fill the disk.
Duplicate small things on purpose. Our websites do not share a codebase, so the small logging module is copied into each one rather than turned into a shared package. For a few dozen lines, keeping copies in sync is cheaper than maintaining a library.
Which service this is
This is n8n automation at its simplest: connect the tools a business already uses so information reaches the right person immediately. The part worth attention is not the happy path but the fallback, and we apply the same thinking to every client workflow we build.
