What to Monitor on 3CX When You Manage It for Other People

Key takeaways:

• Monitoring one 3CX system is a health check. Monitoring forty is a different job, and 3CX doesn’t ship the tooling for it
• Trunk registration and backup age catch more real outages than CPU and RAM ever will
• The 3CX Partner Portal is an inventory list, not a monitoring tool: no alerting, no thresholds, no history
• Alert on things a technician can act on tonight. Everything else belongs on a dashboard, not in someone’s inbox
• Route alerts into your PSA rather than email, or they get triaged by whoever happens to be looking

The Short Version

Monitoring 3CX for other people means watching seven things: trunk registration, core service state, backup age, licence and maintenance expiry, certificate expiry, version and patch status, and endpoint check-ins. Trunk registration and service state are the two worth alerting on immediately; the rest belong in reports and calendar reminders.

3CX itself doesn’t provide this across systems. The admin console covers one instance, and the Partner Portal lists your instances without alerting on them, so fleet monitoring needs something outside 3CX.

Monitoring One System and Monitoring Forty Are Different Jobs

If you run a single 3CX instance for your own company, monitoring is mostly a non-problem. You notice when phones stop working. Somebody tells you immediately.

Managing 3CX for other people breaks that feedback loop in a specific way: the person who notices the problem is your customer, and by the time they’ve noticed, you’re already late. A trunk that dropped at 6pm doesn’t announce itself. It sits there until the first person tries to call out the next morning, and then it arrives as an angry phone call rather than an alert.

So the goal isn’t really “monitoring” in the server sense. It’s shortening the gap between something breaking and you knowing about it, across every system you manage, without hiring someone to click through consoles all day.

3CX doesn’t ship that. It gives you a good admin console for one system at a time. That’s a reasonable thing for 3CX to build and a genuinely awkward gap for a partner running dozens of instances.

The Signals That Actually Predict Outages

Most infrastructure monitoring habits transfer badly to phone systems. CPU and memory graphs feel like monitoring, and they almost never catch the thing that takes a PBX down.

Here’s what does, roughly in order of how often it bites people:

Trunk registration. This is the big one. A SIP trunk that unregisters takes out inbound and outbound calling for that customer completely, and it can happen for reasons entirely outside the PBX: the carrier’s side changed, a firewall rule got rewritten, a static IP moved. Nothing inside 3CX looks broken. Calls just fail.

Backup age. Not whether backups are configured, but when the last one actually completed. Configured-but-failing is the normal state of a neglected backup job, and you find out during a restore.

Licence expiry. A lapsed licence is an entirely self-inflicted outage, and it’s on a calendar, so there is no excuse for being surprised by it. Same for the maintenance dates that gate updates.

Certificate expiry. Expired certs break provisioning, apps, and web client access in ways that generate confusing tickets rather than obvious ones.

Service state. Whether the core 3CX services are actually running, as distinct from whether the host machine responds to a ping. A pingable server with a stopped service is the most misleading kind of green.

Version and patch status. Which of your systems are behind, and which are behind on something with a security advisory attached.

Endpoint status. Phones that stopped checking in. One offline phone is a desk that moved. Thirty offline phones at one site is a switch or a VLAN change.

Call quality. Worth watching, but be careful how you use it. Quality data is genuinely useful for diagnosing a specific complaint after the fact, and much less useful as a fleet-wide alert, because “quality dipped” is rarely something a technician can act on at 2am.

Notice what isn’t on that list: disk space and resource graphs. They matter eventually. They’re just not what breaks.

Why the 3CX Partner Portal Isn’t Enough

Every 3CX partner has access to the Partner Portal, and it’s worth being precise about what it does. You activate it from the management console, link it to your Reseller ID, and you get a list of the instances tied to that ID.

That’s inventory. It answers “what do I have and what licences are on it.” It’s free and you should absolutely use it for that.

What it doesn’t do is alert you. There are no thresholds, no notification routing, no PSA integration, and no history to look back through when a customer asks what happened last Tuesday. Nobody at 3CX has claimed otherwise. It’s a portal, not a monitoring platform.

The failure mode we see most often is a partner who set up the Partner Portal, ticked “monitoring” off the list, and is functionally still relying on customers to report outages.

Setting Thresholds Per System, Not Globally

The first real monitoring setup almost always gets configured once, globally, and then quietly ignored within a month because it produces too much noise.

The reason is that your systems aren’t comparable. A twelve-extension dental office and a two-hundred-seat contact centre have different normal. A threshold tuned to catch problems at the contact centre will fire constantly on the dental office, and one tuned for the dental office will miss real problems at the contact centre.

Two things help. First, set thresholds per alert and per system rather than fleet-wide, so an aggressive trunk check on your revenue-critical customers doesn’t mean the same aggression everywhere. Second, be honest about check frequency. Checking a trunk every thirty seconds is reasonable for a customer where a ten-minute outage is a serious incident. It’s overkill for a site that’s closed at night, and every unnecessary check is one more chance to generate a false positive during a brief network blip.

In Controvo, check intervals are configurable per alert, down to every thirty seconds. That number matters less than the fact that you get to choose it per alert rather than accept one global setting.

Alert Fatigue Is the Actual Failure Mode

Most monitoring projects don’t fail because they missed something. They fail because they cried wolf until people stopped reading the emails.

The filter that works: does this alert tell a technician to do something tonight? If yes, alert. If no, it belongs on a dashboard someone reviews weekly.

Trunk down: act tonight. Backup hasn’t run in nine days: act this week, so it’s a report, not a page. Licence expires in sixty days: act this month, so it’s a calendar item. Call quality dipped on one extension yesterday afternoon: interesting during a diagnosis, useless as a 2am page.

It also helps to distinguish “this is broken” from “this recovered on its own.” A trunk that dropped and re-registered ninety seconds later is worth logging and worth reviewing if it happens nightly. It is not worth waking anyone up for.

Get Alerts Into Your PSA, Not Your Inbox

Monitoring that emails a shared mailbox has the same problem as no monitoring: nothing owns the alert. Whoever happens to be reading the mailbox decides whether it matters, there’s no record of who looked at it, and it doesn’t show up in the same queue as the rest of your work.

Alerts should create tickets. A trunk-down alert should open a ticket automatically, attach itself to the right customer, and close when the trunk comes back. That gives you assignment, an audit trail, SLA timing, and the ability to answer “how often does this customer have trunk problems” without going through anyone’s email.

Controvo integrates with ConnectWise for exactly this. Whatever tool you use, the test is the same: does an alert land in the queue your technicians already work from, and does it close itself when the condition clears?

A Reasonable Setup, Concretely

If you’re starting from nothing, this order gets you most of the value quickly:

The first two are worth doing this week. Everything below them can wait until those two are quiet and trusted.

Frequently Asked Questions

Does 3CX have built-in monitoring for multiple systems?

No. The admin console monitors the system you’re logged into, and the Partner Portal lists the instances tied to your Reseller ID without alerting on them. Monitoring across systems requires something outside 3CX.

Do I need to install an agent on each PBX?

Not necessarily. API-based tools connect through 3CX’s own interfaces with nothing deployed on the client system, which also means nothing to patch or uninstall later. Agent-based approaches exist and give you host-level metrics, at the cost of maintaining software on every customer’s server.

Can I use PRTG or Zabbix for this?

Yes, and plenty of partners do, particularly where a monitoring platform is already in place. You get generic host and service checks. What you don’t get without significant custom work is 3CX-specific awareness: per-trunk registration state, licence dates, backup ages, and the rest.

How quickly should I know a trunk has dropped?

Fast enough to fix it before the customer’s next call attempt, which in practice means seconds to a couple of minutes rather than the fifteen-minute default a lot of generic tooling ships with.

What’s the difference between monitoring and management?

Monitoring tells you something is wrong. Management lets you fix it without logging into the PBX. Most tools in this space do the first. Fewer do the second, and the distinction is worth being clear about when you’re comparing them.

Related reading, if this is the problem you’re working on:

• Which tool should you use to manage multiple 3CX systems? — a comparison including the ones we don’t build
• The 3CX Partner Portal is free. Here’s what it doesn’t do. — where the free option stops being enough
• How to back up 3CX across every customer you manage — backup age is on the monitoring list above, and this is the policy behind it