A useful page tells the next responder where to begin

“Queue too large.” That is the whole message on the phone. Somewhere, something is waiting. Unfortunately, so is the person who has just been asked to fix it: waiting to learn which queue, whose work is stuck and what they can usefully do.

A page, a notification urgent enough to interrupt someone, should bring those answers with it. Say what people cannot do, who can help and where to start looking. The recipient should not need yesterday's conversation to make sense of tonight's message.

Consider the fictional Dispatch service. Customers ask it to export reports. The website is still accepting requests, yet the oldest report waiting for a worker is twelve minutes old. Customers were promised five. More reports keep joining the line. We have a map of the service and its dependencies, along with contacts for the worker and storage services. Now we need a message that puts those pieces within reach of the next responder.

Twelve minutes tells us something a queue count cannot

A thousand tiny reports might be gone in moments; ten enormous ones might take hours. Counting jobs does not tell us how much work is waiting. The age of accepted work, and whether it actually finishes, brings us closer to the customer's question: where is my report?

Before calling those twelve minutes a broken promise, check which reports we are looking at. They must belong to the group covered by the five-minute deadline, and their timestamps must be trustworthy. Otherwise the message could sound precise while describing the wrong work.

For Dispatch, the reason to interrupt someone is not an impressive-looking number. Accepted exports are missing their deadline, and waiting could let more of them do the same. The observation needs to come from somewhere that can see that threatened or failed operation, not merely from a website that still accepts requests. The responder can investigate worker progress and storage behavior, then determine whether the service owner should limit new submissions while the backlog recovers.

Give the responder a place to put their first question

Here is a fuller version of that phone message:

Dispatch exports: completion deadline missed for accepted work in region A. Oldest queued export is 12 minutes; backlog grew from 100 to 180 in 10 minutes. API acceptance is healthy. Owner: Dispatch on-call. First check: compare worker completion and storage latency for region A over the linked interval. Escalate storage failures to its on-call; traffic controls require the service owner.

Now the recipient has somewhere to begin. Region A narrows the search. Ten minutes gives the graphs the same stretch of time. “API acceptance is healthy” says the request-handling part still works; it does not say the reports arrive. The message names an owner, points to help for storage failures and leaves traffic controls with the person authorized to use them.

Notice what it does not say: “Storage is broken.” It asks the responder to compare worker completion with storage latency, the time storage requests take. If workers have stopped taking jobs while storage requests behave normally, worker startup and lifecycle deserve a look. If workers are active but spend their time waiting for storage writes, restarting every worker could add disruption without delivering another report.

Both situations can produce a growing queue. The comparison helps choose between them before activity is mistaken for progress.

The queue shrinks. Did anyone get their report?

That downward line is a welcome sight. It is not yet an answer. Jobs can leave a queue because they finished, expired or were discarded. Only one of those explanations gives the waiting customer what they asked for.

For this exercise, follow the delayed exports to their outcomes and check whether newly accepted work is finishing within the promised time. Include those checks in the response guidance. The person handling the page needs a way to recognize recovery, not just a way to make the notification go quiet.

Some questions can wait until morning

Suppose CPU use briefly rises, but the reports keep arriving on time. That may be worth investigating during working hours. A ticket can carry the trend and a specific question to answer. Sending the same information to someone's bedside repeatedly does not make it more urgent.

We need not wait for a customer to suffer before paging, either. A component signal can reveal an approaching failure early enough to prevent it. But the connection must be understood, and the recipient must have a useful immediate response. What can this person do now? How would waiting change the outcome? A familiar threshold is not a substitute for either answer.

The message still has to reach someone

A query can detect the right condition while the person who needs to know remains unaware. In a lab or an agreed exercise, follow the notification to its intended responder. Check the link, the scope it shows and the acknowledgment. Before sending any test page, use the live rota's agreed exercise procedure. An unannounced test is still an interruption to the person receiving it.

In the test, remove the source metric as well. A system reporting no failures is not the same as a system reporting nothing. Decide how the notification should handle each situation rather than allowing silence to look like health.

If the message arrives late, trace the delay in parts: the wait before detecting the problem, the time spent evaluating the condition and the time spent delivering the notification. Changing the query will not, by itself, repair a slow delivery route.

Finally, hand another reader the draft page and its response guidance without a spoken explanation. Can they tell which reports are affected, choose the first comparison and describe what recovery would look like? Their questions show where the message still depends on you being there.

“Queue too large” leaves someone holding a phone and a mystery. A useful page lets them put the phone down and begin.

Sources

Alerting on SLOs discusses urgency and budget-consumption tradeoffs. Dispatch, its notification and its thresholds are fictional teaching examples, not a report of a real incident.