On our n8n hosted instance we’ve configured an OTLP collector (Dash0 endpoint). After initial set up it started sending data, but everytime it stops sending data after a couple of hours without any error/alert being raised.
Only after we change a setting in the OpenTelemetry config or if we sent a test trace, it will continue again, but after a couple of hours it again stops sending data.
This problem occurred 3 times already in one week.
Telemetry Config:
Startup connectivity timeout = 20000ms
Trace sample rate = 1
Include node spans = True
Inject outbound traceparent = True
Track published workflows only = True
What is the error message (if any)?
Telemetry data is not being sent to the connector anymore.
Hi @Giel_Derks
Nothing in the OpenTelemetry surface retries a stalled exporter. The full variable set is the endpoint, the tracing path, headers, service name, sample rate, the two span toggles and a startup connectivity timeout, with no retry, backoff or export timeout anywhere. Saving settings reloads the exporter without a restart, which is why a config change and the test trace both revive it while ordinary executions do not.
Tracing is Preview from 2.19.0, so there is no setting on your side that fixes this. The exporter diagnostics only get detailed at N8N_LOG_LEVEL=debug, which Cloud does not expose, so send the instance URL, 2.35.4 and the timestamps of the three stalls to help@n8n.io and have them read the logs.
This looks like the OTLP exporter/connection getting stuck after being idle for a while.
I’d check these first:
Dash0/OTLP endpoint — confirm it stays reachable continuously and isn’t closing idle connections.
n8n logs — increase logging and check around the exact time telemetry stops, especially OTEL/exporter errors.
Reduce span volume — with Trace sample rate = 1 and node spans enabled, you may be sending a very large amount of data. Try a lower sample rate temporarily.
Test with a different OTLP endpoint/collector to see whether the problem follows n8n or Dash0.
Since changing the OTEL setting immediately wakes it up, I’d also suspect an n8n OpenTelemetry exporter/connection lifecycle issue. If reproducible, report it to n8n with the timestamps and logs.
The important clue is: it stops silently, then starts again when you touch the OTEL configuration. That points more toward the telemetry exporter/connection becoming stuck than your workflows causing the problem.
The clue nobody has used yet is the shape of the gaps, and you already have the data to read it without any access you don’t have.
Both answers above land on “the exporter gets stuck”, which fits. But there are two very different things that both look like that, and they are told apart by when the stalls start, not by what the logs say:
If the gap always opens roughly the same amount of time after the previous activity — an hour, two hours, whatever it is for you, but the same each time — that is an idle connection being dropped somewhere between n8n and Dash0, and the exporter never learning it died. A long-lived OTLP connection that goes quiet gets closed by whatever sits in the middle, and writes into it afterwards go nowhere without erroring.
If the gaps start at unrelated intervals, that is the exporter itself wedging, and it belongs in a support ticket.
You can check which one you have from Dash0 alone: take the last trace before each of the three stalls and the first trace after n8n came back, and look at the interval between them. Three data points is enough to see a constant.
Why it matters for you specifically: you’re on Cloud, so you cannot change protocol or add keepalive. If it is the idle case, the workaround that fits Cloud is keeping the pipe warm — anything that guarantees a trace at least as often as that interval. Track published workflows only = True makes quiet periods more likely, because nothing running means nothing exported.
The general shape of this is the one that costs people the most time in n8n: a thing that keeps reporting success while it has silently stopped doing the work. It’s what we built CatchLeak to catch in workflows. If you want, send me a quiet export and I’ll read it for that class of silent stall and tell you what I find — no charge, whether or not it turns out to be this.