Guides

Amazon Connect's real-time dashboards are good at showing you a queue backing up. The trouble is that somebody has to be looking. At 2am, in a meeting, or on a weekend, nobody is, and the first sign of trouble is often a complaint the next morning.

Here are the four common ways to get told instead, what each one is good at, and what's worth alerting on.

1. Somebody watches the dashboard

The real-time metrics report shows contacts in queue, the oldest contact and agents available, per queue. During staffed hours, a supervisor glancing at it works well. It stops working the moment that person is busy, away or asleep, so on its own it isn't an alerting plan.

2. CloudWatch alarms on Connect's queue metrics

Amazon Connect publishes metrics to Amazon CloudWatch, including per-queue figures such as QueueSize and LongestQueueWaitTime in the AWS/Connect namespace. You can put an alarm on either one, with a threshold and a period, and send it to an Amazon SNS topic that emails a list, sends a text, or runs a Lambda function.

It's native, cheap, and a good starting point. The gaps show up the first time it fires at night:

• It reaches a fixed list, not whoever is on call. Rotations change weekly; SNS subscriptions don't.
• There's no escalation. If the person it texts is asleep, nothing tries anyone else.
• There's no acknowledgment. Either everyone on the list is woken, or nobody knows whether someone is handling it.
• A phone call is extra work. SNS doesn't place voice calls; you'd build that yourself.

3. A general incident-paging tool

If your organization already runs an on-call tool for IT, you can point a CloudWatch alarm at it and get rotations, escalation and acknowledgment. That's a solid answer if the tool is already there. Two things to know: someone has to wire and maintain an alarm per queue, and the tool knows nothing about Amazon Connect, so the person it wakes still needs a laptop to do anything about the queue.

4. A paging app built for Amazon Connect

This is what we built Standby to do. Rules watch your queues directly, a rotation decides who is on call, and the page goes out as a notification, then a phone call through your own Connect instance, then the next person, until somebody acknowledges. The person on call can see what's wrong and cap or close the queue from their phone; the change undoes itself when the time is up.

Whichever route you choose, the rules matter more than the tool.

What's worth alerting on

• Contacts waiting above a number, for a few minutes. A threshold on a single reading fires on every burst. Require it to hold for several readings, or a few minutes.
• The longest wait passing your service target. This catches a queue that's moving slowly even when it isn't long.
• No agents available while the queue is open. The staffing gap: a shift that didn't show up, or everyone stuck in a meeting.
• Service level below target over the last half hour. Slower, but it reflects what customers actually experienced.

Set thresholds per queue. A support queue with five waiting is normal; an emergency line with one waiting may not be.

Before it wakes anyone

1. Run new alerts quietly for a week and look at what they would have done. A rule that would have fired ten times on a normal Tuesday will be ignored by Friday.
2. Decide how loud each alert is: a notification during the day, a phone call only for what can't wait until morning.
3. Test the whole path with a drill, end to end, on the phone of the person who'll be on call. Do Not Disturb silences calls unless the number is allowed through.

A queue that backs up at 2am is going to happen. The goal is that the right person hears about it within minutes, from something they trust, with a way to act on it.

More: all guides · Standby, the paging app for Amazon Connect