Zyntops Log: why a system should measure itself

An automated flow with no traceability is a black box. It works, until the day it doesn’t, and then nobody knows when it started failing, how long it had been failing, or how much savings were lost in the meantime. Worse still: if nobody measures how much time the system saves when it’s working correctly, the savings figure is a sales promise, not a verifiable fact.

Zyntops Log fixes this with a simple principle: any system that automates a process should generate, as part of its normal operation, the evidence that it’s doing its job well.

The black box problem

When a process is automated without instrumentation, the only signal that something is wrong is usually a complaint: “this never arrived,” “the report wasn’t generated,” “the ticket is still open.” By then, the problem may have been active for days. And when everything is going well, there’s no signal at all — which looks positive, but means the only proof of the system’s value is the absence of complaints, not a concrete figure you can show to whoever paid for the project.

Instrumentation isn’t optional in a well-designed system. It’s the difference between “we think this works” and “this works, and here’s the record that proves it.”

Anatomy of a start and end timestamp

The technical implementation is deliberately simple, because complexity is the enemy of reliability in a monitoring system. In every n8n flow, two lightweight nodes get added:

• A node at the start of the flow that records: a unique execution ID, the process name, the start timestamp, and minimal context data (for example, what triggered the run).
• A node at the end of the flow (or one per exit branch, if the flow has branches) that records: the same ID, the end timestamp, the outcome (success, error, or handled exception), and any relevant metric for that specific process.

An example log entry, simplified:

{
  "id": "flow-reconciliation-2026-04-18-0731",
  "process": "erp_bms_invoice_reconciliation",
  "start": "2026-04-18T07:31:02Z",
  "end": "2026-04-18T07:31:09Z",
  "duration_seconds": 7,
  "estimated_manual_duration_seconds": 420,
  "outcome": "success",
  "authorized_by": "maria.lopez@client.com"
}

Those seven seconds of automated execution, compared against the 420 seconds the manual version of the same step used to take, are the minimum unit of data that feeds the savings report. No figure gets estimated after the fact: it’s calculated by accumulating these real records, run after run.

From individual record to monthly report

A single record has little value on its own. The value shows up when you aggregate them: by summing the estimated manual duration of every run in a month and subtracting the real duration, you get the actual time freed for that process, not a projection. Multiply that time by the hourly cost defined in the original Friction Map, and you get the real economic savings for the month.

The automatic monthly report the client receives includes, at minimum: number of executions of the process, success rate versus handled exceptions, accumulated hours freed, and estimated savings in euros. Nobody has to request it or build it by hand — it’s a scheduled query over the same records the system generates while operating.

This is the same mechanism that backs up the 80% reduction figure shown in the website’s calculator: it’s not a marketing number, it’s the average observed when comparing real duration against estimated manual duration across processes already instrumented with Zyntops Log.

Mapping responsibility

Beyond measuring time, Zyntops Log records which user authorizes each task, usually through WhatsApp or an API call when authorization requires human intervention (approving a payment above a certain amount, for example). This turns the log into more than a performance metric: it’s also an audit trail of who decided what and when, useful both for resolving incidents and for meeting internal traceability requirements.

Precisely because that record contains personal data (who authorized each action), it’s treated as such in the service’s Privacy Policy: its purpose, legal basis, and retention period are defined just like any other personal data the system processes.

The core idea

A system that doesn’t measure itself forces you to trust it on faith. A system instrumented with start and end timestamps at every critical point turns that faith into a verifiable number every month: how much time was freed, how much was saved, and who decided what along the way. That’s the difference between automating a process and building infrastructure that can actually be audited.