Monitoring channels

The monitor is the board you leave open. It answers one question quickly: is anything wrong right now?

What it shows

For each deployed channel:

• Lifecycle state — deploying, running, draining, stopped, or errored.
• Queue depth — how many messages are waiting. A queue that grows and does not shrink is the earliest signal of a downstream problem.
• In-flight count — messages currently being processed.
• Throughput and error rate over the recent window.

Reading queue depth

Queue depth is the most useful number on the page. A brief spike is normal — a batch arrived, or a destination was momentarily slow. A depth that climbs steadily means the channel is receiving faster than it can deliver, which is nearly always a downstream system rather than the channel itself.

When a channel is saturated, the engine applies backpressure rather than dropping messages: HTTP listeners return 503 with Retry-After, and MLLP listeners return a retryable NACK.

Lifecycle control

You can start and stop a channel from the monitor. Stopping drains — in-flight messages finish before the task exits, rather than being cut off mid-pipeline.

Throughput limits

Throughput is capped by plan: 5 messages per second on Free and Team, 50 on Enterprise. Sustained traffic above your plan’s rate will show up as growing queue depth.

Message volume behaves differently from rate: exceeding your included monthly volume is soft, with notifications at 80% and 100%, and traffic is not stopped. See Managing your subscription.

When something is wrong

The usual path from a monitor alarm:

1. Monitor tells you a channel’s queue is growing.
2. Messages tells you what is failing and why.
3. Alert rules make sure you find out next time without watching the board.