A contact centre is a live, customer-facing system. When something breaks, every minute is measured in abandoned calls and missed SLAs — and the person on duty when it happens is rarely the person who built it. Runbooks are how you make sure the response doesn't depend on one engineer's memory or availability.
This guide covers what a runbook is, why Amazon Connect specifically needs a good library of them, the standard sections each runbook should have, and the specific runbooks a typical Connect operation should write — with worked examples.
What Is an Amazon Connect Runbook?
A runbook is a documented, step-by-step procedure for handling one specific operational situation. It answers, for whoever is on duty: what do I check, what do I do, who do I call, and what do I tell people? — in an order they can follow under pressure without having to think it through from scratch.
A runbook is not the same as your solution design document (which describes how the system is built) or your contact flow documentation (which describes how calls route). A runbook describes what to do when a specific thing goes wrong or a specific routine task needs performing. The best ones are boring, literal, and copy-pasteable at 3am.
Why Amazon Connect Needs Runbooks Specifically
Three things about Amazon Connect make a good runbook library especially valuable:
- It spans many AWS services. A single customer journey might touch Connect, Lambda, API Gateway, DynamoDB, Lex or ACXD, Contact Lens, and S3. When something fails, the first job is working out which layer — and a runbook that lists the checks in order saves you flailing.
- Failures are often integration-side, not Connect-side. The platform itself is highly available; most real incidents are a Lambda timing out, a downstream API being down, a certificate expiring, or a bad deployment. Runbooks point responders at the usual suspects first.
- The blast radius is immediate and customer-facing. Unlike a batch job, a broken contact flow is losing live calls right now. Speed of diagnosis matters more than almost anywhere else, which is exactly what runbooks buy you.
Where runbooks fit in the project: they're an operational workstream deliverable, owned by the Operations/BAU Support Lead and Service Introduction Lead. If you're planning a project, they belong in your backlog and your roles matrix — see the Jira backlog and roles & responsibilities guides.
What to Include: The Anatomy of a Runbook
Every individual runbook should follow the same structure, so responders always know where to look. These are the sections to include:
| Section | What it contains |
|---|---|
| Title & ID | A clear name and a reference ID (e.g. RB-07) so it can be cited in alerts and tickets |
| Trigger / scenario | The exact symptom or alert that means "use this runbook" — e.g. "callers hear silence after the welcome prompt" |
| Severity & impact | Priority (P1–P3), what the customer experiences, and which SLAs are at risk |
| Owner & last reviewed | Who maintains it and the date it was last verified as accurate |
| Prerequisites / access | What the responder needs — console roles, CloudWatch access, the on-call bridge, relevant account IDs |
| Diagnostic steps | Numbered checks, in order, to confirm the cause (narrowing from "is it Connect or a downstream system?") |
| Resolution steps | The numbered actions to fix it, with exact console paths, CLI commands, or links |
| Rollback / workaround | If you can't fix it fast: how to revert the change, or a temporary workaround (e.g. an emergency closed message) |
| Escalation path | Who to contact, when, and how — named roles/teams, AWS Support (and your support tier), out-of-hours contacts |
| Communication steps | Who to tell and what to say — stakeholders, status page, the business, and when to send updates |
| Post-incident actions | Logging the incident, raising a problem ticket, and feeding findings into a post-incident review |
The two sections people skip and regret: the rollback/workaround and the communication steps. Under pressure, teams fixate on fixing the root cause and forget they could restore service faster with a workaround, and forget to tell anyone what's happening. Make both mandatory in your template.
Which Runbooks You Actually Need
You don't need a runbook for everything — you need one for every situation that is likely, high-impact, or time-pressured. For a typical Amazon Connect operation, that list looks like this:
Incident runbooks (something is broken)
- Full or partial outage — no calls connecting, or a whole queue/service line down
- Inbound number not working — a specific DID or toll-free number failing
- Degraded voice quality — audio issues, latency, one-way audio
- Lambda / API integration failure — a data dip timing out or erroring in a flow
- Lex / ACXD bot failure — self-service not understanding or not responding
- Agent login / CCP issues — agents can't log in, go available, or take contacts
- Queue or routing misconfiguration — contacts going to the wrong place or stuck
- Recording / storage failure — recordings not saving to S3, compliance exposure
Change & operational runbooks (something is being done)
- Bad deployment rollback — reverting a release that broke production
- Go-live / cutover — the step-by-step for launch day and the hours after
- Scheduled change — the standard process for applying a planned change safely
- Disaster recovery — failover to a secondary region or standby instance
- Routine operational tasks — adding/offboarding agents, updating hours of operation, emergency closures, holiday messages
Start small, grow from reality. Don't try to write all of these before go-live. Write the outage, go-live, rollback, and emergency-closure runbooks first (the ones you can't afford to improvise), then add a new runbook every time an incident happens that didn't have one. Your runbook library should grow from real events.
Worked Example Runbooks
Here are three condensed examples showing the structure in practice. Real versions would carry the full section set from the table above; these show the shape and the Connect-specific detail.
RB-01: No Calls Connecting (Full Outage)
Trigger: Callers can't get through, or real-time metrics show inbound calls dropping to zero.
Diagnose (in order):
- Check the AWS Health Dashboard for an Amazon Connect service event in your region.
- Confirm the phone number is still claimed and associated with the correct flow in the Connect console.
- Check the flow hasn't been edited/published badly — review the "Set" blocks and any recent changes.
- Check CloudWatch for Lambda errors/throttling if the entry flow calls a data dip.
- Confirm hours of operation aren't accidentally closing the contact centre.
Resolve / workaround: If a recent deployment caused it, invoke RB-09 (rollback). If root cause isn't immediate, apply the emergency message flow so callers hear a holding message rather than silence.
Escalate: AWS Support (Business/Enterprise tier) via a severity-appropriate case; notify Operations Lead and Exec Sponsor.
Communicate: Update stakeholders within 15 minutes; post to the status channel; agree customer-facing messaging with the business.
RB-04: Lambda / Data Dip Failure in a Flow
Trigger: Callers reach the IVR but a lookup fails — they're routed to the error branch, or self-service can't retrieve account data.
Diagnose (in order):
- CloudWatch Logs for the Lambda: errors, timeouts, or throttling.
- Confirm the downstream API/CRM the Lambda calls is actually up.
- Check the Lambda's timeout vs the flow's timeout — a slow dependency can breach the flow's wait.
- Check for a recent deployment of the Lambda or its config/permissions.
Resolve / workaround: If downstream is down, route affected contacts to agents (bypass the dip) until it recovers. If the Lambda regressed, roll back to the last known-good version.
Escalate: Integration/dev on-call; the owning team for the downstream system.
RB-12: Emergency Contact Centre Closure
Trigger: Business requests an unplanned closure (severe weather, site evacuation, major incident).
Steps:
- Activate the pre-built emergency closed flow / override hours of operation.
- Confirm callers hear the correct closure message and are offered a callback or alternative where applicable.
- Notify agents and supervisors that the queue is closed.
- Record the start time; set a reminder to revert when the closure ends.
- Log it and confirm reversion afterwards.
Note: Pre-build the emergency closed flow and message before you ever need it — don't author it live during the incident.
Keeping Runbooks Alive
A runbook that's out of date is worse than none, because it sends a stressed responder down the wrong path with false confidence. To keep them trustworthy:
- Give every runbook an owner and a last-reviewed date. No owner means no one keeps it current.
- Store them where they're reachable during an incident — a wiki, SharePoint, or Git repo that stays up even if part of your environment is down. Don't bury them somewhere only accessible through the system that just failed.
- Review on a cadence (quarterly is common) and after every incident — if a runbook was wrong or missing, fix or write it as a post-incident action.
- Test the important ones. Game-day the outage, rollback, and DR runbooks so you find the gaps in a drill, not a real incident.
- Version-control them. Treat runbooks like the rest of your infrastructure-as-code — reviewed changes, history, no silent edits.
The test of a good runbook: hand it to someone who didn't write it and wasn't involved in building the system, and see if they can follow it to resolution. If they can, it's a real runbook. If they need to phone the author, it's just notes.
Conclusion
Runbooks are the difference between an operation that responds to incidents and one that improvises through them. For Amazon Connect specifically — where failures span multiple AWS services and the impact is immediate and customer-facing — a well-structured runbook library is one of the highest-leverage operational investments you can make. Use the section template above for consistency, write the handful of can't-improvise runbooks first, and grow the library from real events.
Pair this with the products & tooling checklist (what you're operating), the Jira backlog (where runbooks sit in delivery), and the roles & responsibilities guide (who owns them).