Are Slow Consumers Only a JetStream Concept in NATS?

A common community question is whether a “slow consumer” is a JetStream-only concept. It is not.

The term can be confusing because JetStream has a formal resource called a Consumer, but the phrase slow consumer predates JetStream. In NATS, a slow consumer is a client connection that is not receiving data fast enough, causing outbound data buffered for that client to exceed a server-side threshold.

What is a slow consumer?

A slow consumer condition occurs when NATS is sending more data to a client than that client can receive and process. This can happen with core NATS subscribers, JetStream consumers, service responders, leafnode-connected clients, or any other client connection receiving messages.

Common contributing factors include:

• The application is not reading from the client library fast enough.
• The subscriber is doing too much work inline before reading the next message.
• The network path to the client is constrained or unreliable.
• Message size or fanout is higher than the client can sustain.
• The client process is CPU, memory, or I/O constrained.

The important point is that slow consumer is about outbound pressure on a connection, not about whether the message originated from JetStream.

What does the server detect?

At a high level, the server detects that it cannot deliver data to a connection fast enough. In practice the slow consumer condition is triggered when either of these crosses a server-side limit:

• The amount of outbound data buffered for that connection (a pending-bytes limit).
• The time a single write to the connection takes (governed by the server’s write_deadline setting).

Either case means the client is unable to keep up with the rate at which the server is trying to deliver messages to it.

When the server detects a slow consumer on a connection, it closes that connection and records the slow consumer event. Treat this as a backpressure signal: the client, network, or delivery pattern needs attention.

How can I monitor slow consumers?

There are two especially useful server-side signals.

1. Check varz for aggregate slow consumer counts

The NATS server monitoring endpoint varz includes slow consumer statistics for the uptime of that server process.

For example, if your monitoring port is enabled on 8222:

curl http://localhost:8222/varz

Look for the slow_consumers field in the JSON response.

This is useful for dashboards and alerting because it gives you an aggregate count since the server started. It does not, by itself, explain every individual client or application-level cause.

2. Subscribe to system disconnect events

For real-time visibility into disconnects, subscribe to NATS system events:

1
$SYS.ACCOUNT.*.DISCONNECT

You can also subscribe for a specific account instead of using the wildcard.

When a disconnect is caused by a slow consumer condition, the event payload’s reason field contains the text Slow Consumer. The full value also reflects the specific trigger — for example a pending-bytes limit or a write-deadline timeout — so match on the Slow Consumer substring rather than expecting a single exact string.

This is the more direct signal when you need to know when a slow consumer event occurs and which connection was disconnected as a result.

Access to $SYS subjects depends on your system account and authorization configuration, so make sure the monitoring user or service has the required permissions.

Should I rely on debug or verbose logs?

Server logs can be helpful during troubleshooting, but verbose and debug logs are often too dense to be the primary monitoring signal for slow consumers.

For routine operations, prefer structured signals:

• Use varz for server-uptime aggregate counts.
• Use $SYS.ACCOUNT.*.DISCONNECT for real-time disconnect events and the disconnect reason.
• Use logs as supporting evidence when investigating a specific incident.

Is “slow consumer” a persistent connection status?

It is better to think of a slow consumer as a condition or event rather than a durable label you can query for the rest of a connection’s lifetime.

Because a server-detected slow consumer closes the affected connection, there is no live connection left to carry a persistent “slow consumer” status — the system disconnect event is the record of what happened. If you need historical reporting, capture and store the relevant monitoring data or system events in your own observability pipeline.

Practical guidance

If you see slow consumers:

1. Identify whether the events are isolated or increasing over time.
2. Use varz to confirm the server-level trend.
3. Use $SYS.ACCOUNT.*.DISCONNECT to capture real-time disconnects and reasons.
4. Inspect the affected subscriber application for blocking handlers, slow processing, or insufficient concurrency.
5. Review message size, publish rate, fanout, and network path to the client.
6. Consider whether the subscriber should decouple message receipt from processing, scale out, or apply a more appropriate delivery pattern.

Slow consumers are not specific to JetStream. They indicate that a client connection cannot keep up with delivery. Monitor aggregate counts with varz, capture real-time disconnect reasons with $SYS events, and focus remediation on the subscriber, network, or delivery pattern creating backpressure.

Want help from the NATS experts? Meet with our architects to get help tailored to your use case and environment.