.png?width=141&height=141&name=Transact%20(1).png)
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
%201.svg){kind=small}
Quick answer
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.
Key takeaways
What this guide covers.
- An Avaya contact centre is not one system. Communication Manager, Call Center Elite, Application Enablement Services, Experience Portal, session border controllers and media gateways each generate different signals and fail in different ways.
- Estates became harder to monitor between 2020 and 2026 for three structural reasons: hybrid deployment, lifecycle pressure, and multi-vendor sprawl.
- The five failure modes teams escalate most often almost never originate in the Avaya application layer.
- Voice quality is measured, not asserted — MOS estimated against the ITU-T G.107 E-model, per call leg rather than per call average.
- Native tooling and third-party observability answer different questions. Most enterprise estates need both.
- Eight criteria let you evaluate any monitoring tool consistently, including the one you already own.
- Baseline before you alert. Thresholds borrowed from someone else's environment will be wrong for yours.
What's actually inside an Avaya contact centre
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.
Why an Avaya estate is harder to monitor in 2026 than it was in 2020
The estate stopped being one thing.
Three changes, all structural.
The hybrid split
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.
Lifecycle pressure
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.
Multi-vendor sprawl
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 five failure modes teams actually escalate
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.
- One-way or degraded audio on a subset of calls
Signalling completed, so the platform recorded a successful call. The audio path is where it went wrong: codec negotiation mismatch, packet loss on a specific network segment, or a gateway routing media over infrastructure never provisioned for voice. Root cause usually sits in the network or the media path. - Calls connect but route to the wrong skill
Vector logic and skill assignments have drifted, or a CTI link dropped and took integration-driven routing with it while voice carried on working normally. Root cause usually sits in configuration, or in an integration link nobody is monitoring. - Self-service completes and the transfer fails
The IVR worked. The handover to the ACD did not — usually SIP signalling or trunk capacity at the moment of transfer. This one is expensive because the customer has already invested time before it fails. - Agents dropping out of ready state, or desktop desync
Reported as an agent problem or a PC problem. Almost always the health of the CTI session between the desktop and the platform. Root cause usually sits in the integration layer. - Everything reports healthy and customers still complain
The hardest one, and the most common. The estate is being measured on platform availability when the thing degrading is experience. Nothing is down. Calls are just worse than they were. Root cause usually sits in what you chose to measure.
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.
The four layers worth monitoring
Availability is the floor, not the answer.
Layer 1 — platform health
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.
Layer 2 — signalling
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.
Layer 3 — media and voice quality
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.
Layer 4 — contact centre experience
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.
Native Avaya tooling versus a third-party monitoring tool
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.
Eight criteria for evaluating an Avaya monitoring tool
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.
- Component coverage against your actual inventory
Not "supports Avaya" — ask for a published, versioned support matrix and check it against your real component and version list. Vendors who publish one are telling you something. Vendors who will not are telling you something too. - Vendor certification
Has the integration been formally tested through Avaya DevConnect, or is it best-effort polling? Certification is the difference between an integration that survives your next upgrade and one that quietly stops reporting. - Depth on the media path, not just the application
Can it show you one call, leg by leg, from endpoint through gateway and session border controller to carrier? If it can only show averages, it cannot tell you where the audio degraded. - Multi-vendor reach
Your customer journey does not stop at the Avaya boundary. Neither should your visibility. - Deployment fit
On-premises, hybrid and cloud, with data residency you can defend to a regulator. For financial services and public sector organisations in APAC and MEA, this is frequently the criterion that decides it. - Outside-in testing
Can it verify the service works from the customer's side before agents arrive, rather than waiting for a real customer to find the fault? - Time to first finding
How long from installation to something you did not already know? A tool that takes a quarter to configure has cost you a quarter of visibility. - What happens after the alert
Alerts without correlation are noise. Ask how it groups related events, what it points at as probable cause, and whether the person receiving the alert can act on it.
How to monitor Avaya contact centre performance in your first 30 days
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.
- Week 1 — inventory
Every component and version. Every gateway and its vintage. Every trunk group and carrier. Every integration point, including the ones nobody has thought about since they were built. This step is unglamorous and it is the one most often skipped. - Week 2 — instrument all four layers
Turn on collection across platform health, signalling, media and contact centre experience. Set no thresholds yet. You are gathering, not judging. - Week 3 — baseline under real load, including peak
A baseline built on a quiet Tuesday will make every busy Monday look like an incident. - Week 4 — set thresholds from your own data, and define the response
For every alert, answer three questions: what does this mean, who receives it, and what do they do about it? An alert nobody can act on is a notification that trains people to ignore notifications.
Expect the first fortnight to surface things you did not know were happening. That is the point.
How IR Collaborate can help
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.
- Published, versioned platform support
IR publishes its supported platforms list, including vendor-certified coverage for Aura Communication Manager, Aura System Manager, Call Center Elite, Application Enablement Services, Experience Portal, Voice Portal, IP Office and the Session Border Controller for Enterprise. That is criterion 1 above, met with a document rather than a claim. - Multi-vendor by design
The same view across Avaya, Cisco, Microsoft Teams, Genesys Cloud, Oracle, Ribbon and AudioCodes session border controllers, and Verint and NICE recording — without locking your organisation into a single vendor. - Deployment flexibility
On-premises, hybrid or cloud, with consistent visibility regardless of how your communications infrastructure is deployed. - Service level management
IR Collaborate works with Avaya Public Cloud Services to help manage SLAs and provide performance management and reporting. - Iris
The AI assistant embedded in the Prognosis platform, built for natural-language interrogation of observability data.
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.
Frequently asked questions
Conclusion
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.
See how your Avaya estate measures up
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.
