I did a bit of a quick research, but I am using Enterprise so I could not test it.
Yes, expected behaviour, a design limitation, not a misconfiguration.
Graylog serves all outputs from one shared thread pool, and the GELF output has no buffer of its own. When the far end stops accepting, the send call blocks and holds its thread. All output threads park within seconds, the journal stops draining. Graylog staff confirmed it: the GELF and STDOUT outputs have no buffers, the buffered ones are Enterprise. Graylog Community
Because the pool is global, it stalls indexing for every stream, not just the affected one. And once the journal hits its size or age limit, old segments are droppe, real data loss.
So yes: with GELF TCP on Open, all three targets need to stay reachable. No per-output timeout or drop-on-failure exists.
Possible Fixes: run a local relay (Vector, Fluent Bit, syslog-ng) on the Graylog host, point the outputs at 127.0.0.1, and let it handle buffering and retries. Or use GELF UDP, lossy, but can’t backpressure. Alert on journal utilization either way.