How to Monitor 3CX Trunk Health (Without Logging Into 20 Portals)

What 3CX exposes natively

Every 3CX management console has a Trunks page that lists SIP trunks, SBCs, and bridges with their current registration status. The states you'll see:

Registered — the trunk has a valid SIP REGISTER with the provider; calls can flow.
Failed Registration — the REGISTER attempt was rejected (auth failed, provider down, network unreachable).
Unregistered / Not Registered — no REGISTER attempt has succeeded since the trunk was last touched.

That status is exposed in the 3CX Management API under the /xapi/v1/Trunks endpoint, alongside trunk type (Inbound / Outbound / Both), gateway type (SBC / SIP / Bridge), and simultaneous-call usage. Any external monitoring tool worth its salt pulls from there — the alternative is screen-scraping the admin UI, which 3CX changes between versions.

What 3CX doesn't expose well

No multi-instance roll-up
You check trunks one PBX at a time.
No mobile alerts
Native notifications are email only.
No escalation
One inbox, one alert, no rotation.
No PSA ticket creation
Tickets get hand-typed after the customer calls.
No alert deduplication
A provider-wide outage emails you N times — once per affected instance.
No history or SLA reporting
Yesterday's outage is gone unless you logged into the console while it was happening.

Trunk failure modes that actually bite

1. Provider-side registration drop

The most common failure: the carrier's SIP server stops accepting REGISTER attempts. Usually a provider-side outage (their SIP nodes hiccup) or a credentials issue (account suspended, password rotated by accounting). 3CX's status flips to Failed Registration within one REGISTER refresh interval — typically 60 seconds to a few minutes, depending on how the trunk is configured.

What good monitoring catches: the flip the moment it happens, with the provider name in the alert so on-call doesn't have to look up which trunk drives that customer's calls.

2. SBC offline

An SBC backhauls remote phones (often Fanvil X-series hardware sets, or a software SBC on a branch-office Linux box) into the central 3CX. When the SBC drops, every phone behind it goes silent — not just one trunk's calls, but every extension served by that SBC. 3CX shows the SBC under the same Trunks list with a distinct Gateway.Type = "SBC" field.

This is the failure mode that produces "the whole branch office can't dial" tickets. A monitoring tool that distinguishes SBC drops from generic trunk drops can fire a higher-severity alert and an explicit "branch office offline" message, instead of just "a trunk is down."

3. Bridge degraded

A 3CX-to-3CX bridge fails when either side loses its REGISTER. Symptom: inter-office extension dialing breaks while external PSTN trunks keep working. Often the bridge is the most fragile trunk in the fleet because it depends on both PBXes being healthy + the network path between them.

4. License-cap exhaustion

Less obvious failure: the trunk is registered and healthy, but every available simultaneous-call channel is in use. New calls get a busy tone. 3CX reports this as SimCalls / LicensedSimCalls on the trunk row — a registered trunk at 100% utilisation is functionally broken for inbound callers.

Catching this requires polling simultaneous-call usage on every trunk, not just registration state. Most monitoring tools miss it. The fix is a threshold alert: warn at 80%, page at 95%.

5. Network-path degradation (silent failure)

The trunk says Registered, but call quality is degrading because packet loss is creeping up between the PBX and the carrier. SIP keep-alive succeeds (small UDP packets); RTP audio is suffering (constant bidirectional packet streams). Customers complain about choppy calls before any of the native 3CX dashboards register a problem.

The signal here is inferred MOS — a Mean Opinion Score computed from latency, jitter, and packet loss to the trunk's far end. We wrote a separate piece on how MOS scoring works for 3CX. The short version: MOS is the canary that catches "registered but bad" trunks.

The monitoring you actually want

For a single PBX, native 3CX is fine — log in, look at the trunk page, fix it. For a fleet of more than two or three PBXes, here's the minimum useful monitoring shape:

1. Fleet-wide trunk grid

A single screen that lists every trunk on every instance with current status, type, and simcalls usage. Sortable so you can see "all my failing trunks across all customers" in one glance.

2. Trunk-down alert, deduplicated

When a trunk goes from Registered to Failed, fire one alert per trunk, not one per polling cycle. Don't refire until the trunk recovers and fails again. This sounds obvious; most cobbled-together monitoring fails it.

3. Multiple delivery channels

Mobile push to your phone, a PSA ticket (Autotask / ConnectWise / HaloPSA / Syncro), a Slack or Teams message to the team channel. Email is fine as a backup but should not be the only path — email arrives slowly, gets filtered, gets ignored.

4. Voice escalation for criticals

A 3 a.m. trunk drop that goes to push but the on-call's phone is in DND mode is a customer-visible outage by 3:05 a.m. Pro and Enterprise plans on Sikurd place an outbound AI voice call to whoever's on-call when a Critical alert fires. The agent reads the incident aloud: "There is a trunk down on instance Acme HQ. The trunk is Bandwidth-Primary." Acknowledged on the call, or repeated until someone picks up.

5. Granular routing per alert type

Different trunk types deserve different urgency. A primary inbound trunk dropping is page-everyone. A failover trunk that only carries traffic on primary failure is informational. A bridge between two of the same customer's offices is medium. The routing tool needs to let you express this without writing code.

6. Audit trail

Every alert fire, every acknowledgment, every state transition — with timestamps. Without this, post-mortems are guesswork.

How to set this up on your own infrastructure

The build-it-yourself path: write a script that polls /xapi/v1/Trunks on every PBX every 60 seconds, diffs registration state against the last poll, and dispatches alerts via Pushover or a Slack webhook on transitions. Add a SQLite database for history, a cron'd backup job for retention, and a small web UI when the inevitable "I want to see this in a browser" request lands.

Reality: that script is two-to-three days of writing plus ongoing maintenance every time 3CX changes the API shape (which happens between v18 → v20 → v21). MSPs we talk to who tried this path end up either abandoning it after the third 3CX version migration or quietly contracting it back out to an MSP who already runs a monitoring SaaS — which is most of why this category exists.

How Sikurd handles trunk monitoring

The TL;DR is that Sikurd polls every 3CX instance you connect every minute, computes trunk status (Registered / Failed / Unregistered), classifies by gateway type (SIP / SBC / Bridge), tracks simcalls usage, and surfaces all of it on one dashboard. Alerts route through a per-alert-type matrix to push, PSA ticket, webhook, and (Pro+) AI voice call.

Setup is OAuth — you paste your 3CX Service Principal credentials into the dashboard, the instance connects, the trunk grid populates within a few minutes. No agent on the PBX, no firewall changes, no manual data entry. Full feature list for MSPs is here; how it compares to the long-running alternative is here.

Frequently asked questions

How do I know if a SIP trunk is down in 3CX?

3CX shows trunk registration status in the Management Console under SIP Trunks. A trunk is healthy when its status reads "Registered" with a green dot. If it shows "Failed Registration" or any non-Registered state, calls inbound or outbound through that trunk are failing. For multi-instance monitoring, you need an external tool that pulls the registration state from every PBX in your fleet on a polling interval — manually opening each console doesn't scale.

What's the difference between a SIP trunk, an SBC, and a bridge in 3CX?

A SIP trunk connects 3CX to a carrier for inbound/outbound PSTN calls. An SBC (Session Border Controller) is a 3CX-managed appliance that backhauls remote phones to the PBX over a single hardened connection. A bridge connects two 3CX instances together (typically for inter-office calling). All three show up under "Trunks" in 3CX's UI, but they fail differently and need different remediation. Good monitoring tells you which kind dropped, not just "a trunk is down."

How often does 3CX check trunk registration?

3CX itself doesn't poll trunks on a fixed interval — it relies on the SIP REGISTER refresh cadence negotiated with each provider (typically 60–3600 seconds). External monitoring tools poll the 3CX management API at their own interval; Sikurd defaults to roughly once per minute per instance.

Can I get woken up by phone if a trunk fails at 3 a.m.?

Yes — but only on a tool that explicitly supports voice-call alerts. Native 3CX only emits email and event-log notifications. Sikurd's Pro and Enterprise tiers can place an AI voice call to your on-call rotation when a trunk drops, so push notifications that get missed in DND mode still wake someone up.

Should I monitor every trunk equally, or weight some higher?

Weight by call volume and revenue impact. A primary outbound trunk that handles 80% of a customer's calls deserves immediate escalation; a fail-over trunk that only carries traffic when the primary's down deserves a warning but not a 3 a.m. call. Sikurd's per-alert-type routing matrix lets you set this granularity once per tenant.