The Support Ticket That Opens Itself: Automatic Tickets from LibreNMS When a 3CX Host Goes Down
The Call You Never Want to Take
A customer's 3CX PBX goes offline at 08:14. By 08:40 the phones are dead, the receptionist has tried three times to reach someone, and by the time your support desk picks up, the conversation opens with "why is our phone system down and why didn't you know?"
For a MSP or telecom reseller, that call is the whole business in miniature. You are paid to keep infrastructure running, and the moment the customer notices a fault before you do, the relationship shifts. You are no longer the trusted operator. You are the vendor who was asleep.
The uncomfortable part: you almost certainly did know. Your monitoring system saw the host stop responding to ICMP within seconds. The alert fired. It just landed in an inbox, or a Slack channel, or a dashboard that nobody was watching at 08:14 in the morning.
The Gap Between Knowing and Acting
Here is the old world most support teams live in. Monitoring lives in one tool, LibreNMS or similar, watching hosts and firing alerts. Support lives in another, the Helpdesk, where tickets are created, prioritised, assigned, and resolved. Between the two sits a human being who is supposed to read the alert, recognise which customer it belongs to, look up the right technical contact, and open a ticket.
That human is the bottleneck. At night, on weekends, or during a busy shift, alerts pile up faster than anyone can triage them. The alert that matters, a production 3CX host down for a paying customer, sits in the same queue as a routine disk-space warning. Nobody has translated "host unreachable" into "customer Acme Telecom is losing calls right now, and Marie Dupont is their technical contact."
The shift that closes this gap is not a new monitoring tool or a bigger support team. It is a connection. When the system that detects the fault can talk directly to the system that tracks the work, the human bottleneck disappears, and the ticket opens itself.
What Proactive Support Actually Looks Like
Picture the same 08:14 outage, wired differently.
LibreNMS detects that the 3CX host stops responding. Instead of dropping an alert into a channel, it calls the BlueRockTEL Helpdesk API. In one automated flow it:
- Identifies the customer from the PBX hostname. The alert carries
acme.3cx.fr; BlueRockTEL resolves that host to the customer account it belongs to. - Finds the right technical contact on that account, so notifications reach the person who can act, not a generic mailbox.
- Opens a prioritised ticket in the Helpdesk, tagged as a monitoring event, with the alert details, timestamp, and failed check already in the body.
- Attaches the alert data as the first reply, so the assigned technician sees exactly what failed and when, with no back-and-forth.
By 08:15, before the receptionist has even reached for the phone, there is a High-priority ticket in your Helpdesk, assigned, with full context, linked to the right customer and the right contact. Your technician is already looking at it. In many cases the issue is resolved, or a callback is placed, before the customer notices anything at all.
That is the promised land: a support team that acts on faults instead of reacting to complaints. The best outcome is not a ticket resolved quickly. It is a customer who never knew there was a problem.
Losers and Winners
Two operators run the identical stack: 3CX hosts, LibreNMS monitoring, a Helpdesk. The difference is whether the two are connected.
The first still relies on a human to bridge the gap. Their metrics look fine on paper, but their customers experience every outage as a surprise, and every support interaction starts from behind. Renewal conversations are harder than they should be.
The second has closed the loop. Their tickets are open before the phone rings, their first-response times are measured in seconds because there is no manual triage step, and their customers describe them, unprompted, as "the ones who call us before we call them." That reputation is the entire competitive advantage in managed services, and it compounds at every renewal.
The Ingredients
This works because the BlueRockTEL Helpdesk is not a standalone ticketing tool bolted onto your operation. It shares a single data model with the rest of the platform, which is what makes automatic customer resolution possible. The API can turn a bare PBX hostname into a customer account, a technical contact, and a routed, prioritised ticket, because all of that context already lives together.
Any alerting system that can make an HTTP request can drive it. LibreNMS is the natural fit for MSP and 3CX partners monitoring customer infrastructure, but the same pattern applies to Zabbix, Nagios, Prometheus Alertmanager, or a custom probe. The monitoring system stays exactly as it is. You simply point its alert action at the Helpdesk.
For the technical how-to, including the exact endpoints to resolve a customer from a 3CX hostname, open the ticket, attach the technical contact, and avoid duplicate tickets, follow the step-by-step guide in Opening a Ticket from a Monitoring System.
From Reactive to Proactive
The tools to detect faults have been mature for years. What has been missing is the wiring that turns a detected fault into an action, without a human in the middle at the worst possible moment. Connecting your monitoring to the BlueRockTEL Helpdesk is that wiring, and it is a one-time setup.
Want to see it running against your own Helpdesk? Explore the platform or get in touch for a demo.