Four layers, watched at the same time.
Monitoring an Avaya contact centre means watching four layers at once: the Avaya applications themselves, the signalling that sets up every call, the media path that carries the audio, and the queue and agent activity sitting on top. Native Avaya tools report on the first layer well. Almost every problem a customer actually notices starts in one of the other three.
What this guide covers.
Start with the component map, not the dashboard.
Ask five people in the same organisation what "the Avaya system" is and you will get five answers. That is not carelessness. It is an accurate reflection of an estate that grew one component at a time over fifteen years.
A typical enterprise Avaya contact centre runs some combination of the components below. Each generates different signals, fails in different ways, and needs watching for different reasons. The table lists each component, what it does, what typically goes wrong with it, and the signal worth watching.
| Component | What it does | What breaks | What to watch |
|---|---|---|---|
| Aura Communication Manager | Core call processing and telephony features | Processor occupancy ceilings, failover to standby, licence exhaustion | CPU occupancy, memory, standby server readiness, licence consumption |
| Aura System Manager / Session Manager | Central management and SIP session routing | Routing policy errors, session capacity limits | Session counts, routing failures, entity link status |
| Call Center Elite | Voice routing, skills, agent state, vector processing | Vector misconfiguration, skill assignment drift | Routing outcomes by vector, skill queue depth, agent state transitions |
| Application Enablement Services | CTI, screen pop, outbound dialling, desktop integration | Link drops that take CTI down while voice keeps working | AES link state, CTI session health, event lag |
| Experience Portal | IVR and self-service | Application errors, transfer failures at the ACD handover | Port utilisation, application error rates, transfer success |
| Session Border Controller for Enterprise | Session edge, remote workers, carrier interconnect | Trunk capacity, media relay issues, registration failures | Trunk utilisation, call setup failure cause codes, RTCP from remote workers |
| Media gateways | Media processing and PSTN interconnect | Firmware and vintage mismatch, DSP resource exhaustion | Gateway registration, DSP resource use, firmware version drift |
| Recording and workforce optimisation | Compliance capture and quality management | Silent recording failures | Recording completion rate, storage health |
There is a second lineage as well. Aura Contact Center is a different product from Call Center Elite, with a different history, and some estates run both. If you inherited the environment, confirm which one you actually have before you plan anything around it.
Availability tells you the platform is running. Experience tells you the call was good. They are not the same measurement, and most estates only have the first.
The estate stopped being one thing.
Three changes, all structural.
Avaya launched the Infinity Platform in 2025, giving large enterprise and public sector customers a way to add cloud digital channels, AI and orchestration on top of the Aura and Call Center Elite estates they already run. Avaya positions hybrid and on-premises deployment as architectural choices rather than legacy constraints, which is the right call for organisations carrying data sovereignty or regulatory obligations — and it is a large part of why so many financial services and public sector organisations across APAC and MEA kept voice on-premises.
The consequence for monitoring is that a single customer journey now crosses two operating models with two different telemetry sources. The customer does not experience two systems. Your monitoring does.
Avaya version and gateway support milestones have put a large number of estates mid-upgrade at the same time. Mid-upgrade estates are exactly where mismatched component versions, unsupported gateway vintages and silent capacity ceilings live — and where "it was fine last week" stops being useful diagnostic information.
Avaya rarely runs alone at enterprise scale. There is Microsoft Teams for internal collaboration, often a separate cloud contact centre in one region, third-party recording, and carrier SIP underneath all of it. Watching Avaya in isolation tells you Avaya is fine. It does not tell you the call was fine. We have written more on this in Managing UC&C Multi-Vendor Reality in 2026, and on why on-premises is a deliberate control decision in Hybrid UC in 2026.
"A hybrid estate does not have one gap in visibility. It has two systems watching two halves of the same call, and neither of them sees the handover."
The ticket says the phone system is down. It almost never is.
Every contact centre operations team has a version of this conversation. Something is wrong with calls, the ticket lands with whoever owns the telephony platform, and the platform reports healthy. Here is what is usually happening instead. Note where the root cause sits in each one — it is rarely the application layer.
The pattern is consistent enough to be useful. When an Avaya contact centre misbehaves, the answer is usually underneath the platform rather than inside it — the network, the gateway, the session border, the configuration, the capacity ceiling. That is an argument for watching the infrastructure and the integration points with the same rigour you apply to the application itself.
Availability is the floor, not the answer.
The foundation, and the layer native tooling covers best. Processor occupancy against manufacturer specification, memory and disk, duplication and standby readiness, port network and gateway status, and licence consumption. That last one earns its place for a reason that is not performance: unused stations still holding licences are a recurring, quiet cost in large estates, and increased visibility tends to surface them within days.
SIP trunk utilisation and health, call setup failure rates broken down by cause code rather than counted in aggregate, CTI link state, and registration counts for remote and branch endpoints. Cause codes matter here. "Calls are failing" is not actionable. "Calls are failing with a specific cause code on one trunk group during peak" is.
This is where Avaya call monitoring and Avaya VoIP monitoring converge, and where most customer-visible degradation actually lives.
Mean Opinion Score (MOS) is the standard summary measure, estimated from packet loss, jitter and delay using the E-model defined in ITU-T Recommendation G.107. The G.107 satisfaction bands are the reference point rather than a threshold you invent: broadly, above 4.03 users are satisfied, between 3.60 and 4.02 some users are dissatisfied, and below 3.10 nearly all are.
Two practical notes. Measure per call leg, not per call — a call that traverses an endpoint, a gateway, a session border controller and a carrier has four places to degrade, and an averaged score for the whole call hides which one. And measure continuously rather than sampling, because degradation that only appears at peak is precisely the degradation worth catching. Our guides on network jitter and network latency cover the underlying mechanics, and the VoIP monitoring guide covers the measurement approach in more depth.
The layer that connects everything above it to what the business actually cares about. Queue depth against staffed skills. Abandon rate correlated with media quality, not just with wait time — customers hang up on bad audio as readily as on a long queue, and the two look identical in a report that only tracks duration. Transfer success rate. Self-service containment.
| Layer | What you measure | What it tells you |
|---|---|---|
| Platform health | Processor occupancy, memory, standby readiness, gateway status, licence consumption | The components are running within specification |
| Signalling | Trunk utilisation, setup failures by cause code, CTI link state, registration counts | Calls can be established, and where they cannot |
| Media and voice quality | MOS per G.107, jitter, packet loss, one-way delay — per call leg | The audio was actually good, and which leg degraded it |
| Contact centre experience | Queue depth vs staffed skills, abandon rate against media quality, transfer success, containment | The customer got what they called for |
Knowing what to watch is the easy half. The harder question is what you watch it with.
Both belong in the estate. They answer different questions.
Nearly every platform vendor ships a self-monitoring capability, and Avaya is no exception. It is authoritative about the state of Avaya's own components, because it is built by the people who built them. What it is not designed to do is report on anything outside that boundary — and as the failure modes above show, outside that boundary is where most root causes live.
This is why Avaya leans on DevConnect partners for comprehensive monitoring. It lets Avaya focus on the platform while specialist tooling handles the correlation problem across the wider ecosystem.
| Native platform tooling | Third-party observability |
| Authoritative on the state of Avaya's own components | Correlates state across Avaya, the network, session border controllers and other vendors |
| Ships with the platform, organised per product | Single view of one call across every component it touched |
| Real-time status | History and trending, so you can prove whether a change made things worse |
| Reports in system terms | Reports in service and experience terms |
| Tells you the component is up | Tells you the customer's call was good |
Framed as a replacement argument, this is a false choice. Framed accurately, it is a boundary: native tooling for component truth, third-party observability for the correlation across everything the call touched.
Score whoever you shortlist against the same list.
There is no ranking here, deliberately. The right answer depends on your estate. Apply these criteria consistently to every option you consider, including the tooling you already own.
Baseline first. Alert second.
If you have inherited an estate, or you are standing up monitoring properly for the first time, resist the urge to configure thresholds on day one. Thresholds borrowed from someone else's environment will be wrong for yours.
Expect the first fortnight to surface things you did not know were happening. That is the point.
Visibility across the whole ecosystem, not just the Avaya part.
IR Collaborate, powered by Prognosis, provides performance management, monitoring, optimisation and troubleshooting for Avaya unified communications and contact centre ecosystems. Avaya and IR have worked together since 2009.
What that looks like in practice: within 45 minutes of turning Prognosis on for a large government agency, IR found that Avaya voice call routing had been configured to traverse network segments never designed to carry voice traffic. The organisation remediated before go-live. Without that level of visibility, the first sign of a problem would have been degraded calls at production volume. More on the contact centre use case.
The question was never whether Avaya is working.
For most enterprises running Avaya, the platform is not the risk. Fifteen years of accumulated components, integrations and network paths around it are. As estates split between on-premises voice and cloud digital channels, the gap between "the system is available" and "the customer's call was good" keeps widening — and only one of those two numbers appears on most dashboards.
The organisations that handle this well are not the ones with the most alerts. They are the ones that decided, deliberately, which four layers they were going to watch, and then measured all four.
Work through the eight evaluation criteria against your own environment with our Avaya contact centre monitoring evaluation checklist.
Or see it running against a live multi-vendor estate — request a demo.