Handling Hub-and-Spoke Outages in Mobile Networks: A Practical Guide to Detection, Logging, and Response

In mobile network operations, not every fault is equal. A single site going down is serious. A hub site going down is a different level of problem entirely, because it does not just take one site offline; it takes every child site that depends on it offline at the same time. One ticket in your system might actually represent fifteen sites with no service, and if the people responding to it do not know that from the moment they receive the alert, their response will be calibrated for a single-site incident rather than a multi-site emergency.

This is the fundamental challenge of hub-and-spoke outage management in field operations. The topology matters, and most standard ticketing systems treat every ticket the same regardless of how many sites are affected. The result is delayed dispatch, under-resourced response teams, and reporting that obscures the true scale of the impact.

This article explains what hub-and-spoke outages are in the context of mobile networks, why they need to be handled differently from single-site faults, and how to build a ticketing system in Clappia that captures hub impact automatically, surfaces it in every notification, routes it to a priority queue, and segments it cleanly in your reports.

What Is a Hub-and-Spoke Outage?

In a hub-and-spoke network topology, certain sites act as hubs that provide backhaul connectivity, power distribution, or signal routing to a cluster of smaller dependent sites, called child sites or spoke sites. The hub site is the upstream node. Child sites rely on it to function.

When the hub site experiences an outage, all the child sites that depend on it lose service simultaneously. From a network monitoring perspective, you may see multiple alarms fire at once. From an operations perspective, you have one root cause but several times the impact. Dispatching a single engineer with equipment sized for a single-site repair to a hub-and-spoke outage is one of the most common and costly miscalibrations in field operations.

A hub site outage with fifteen child sites down is not fifteen separate incidents. It is one incident with fifteen times the customer impact. Your ticketing system should reflect that from the first moment the ticket is created.

Hub-and-spoke outages also tend to attract more senior attention and more urgent escalation than single-site faults. Circle heads, regional operations managers, and NOC heads need to know about them immediately, not after the fact when they appear in a daily summary report. The notification and escalation chain for a hub outage is typically broader and faster than for a standard fault.

‍

Why Standard Ticketing Falls Short for Hub Outages

Most fault ticketing approaches, whether in a spreadsheet, a generic helpdesk tool, or a basic mobile form, capture the fault at the site level. You log which site is down, what the alarm is, who is assigned, and when it was resolved. That works well enough for single-site incidents.

For hub-and-spoke outages, the same approach creates several problems:

• Impact is invisible at the ticket level: A ticket for a hub site looks identical to a ticket for a standalone site unless the form explicitly captures whether it is a hub outage and how many child sites are affected. Whoever receives the alert has no way to know the true scope without calling someone.
• Notifications reach the wrong people at the wrong level: A standard fault notification goes to the assigned engineer and maybe a team lead. A hub outage should go to a broader group, including regional heads and NOC leadership, because the decision to escalate resources or invoke an SLA breach protocol is made at a higher level.
• Dispatch is under-resourced: If the response team does not know it is a hub outage until they arrive on site, they may not bring the right equipment, staffing, or authority to make decisions about rerouting traffic or escalating to vendors.
• Reporting does not segment impact correctly: When your monthly SLA report shows total downtime hours, hub outages distort the picture because one ticket represents far more customer-hours of lost service than a single-site ticket does. Without a flag in the data, you cannot segment hub outages from standard faults in your analysis.

The Solution: A Hub Impact Field Pattern in Your Ticketing App

The fix is straightforward, and it lives entirely within your ticketing form. You add three fields that work together:

1. Hub Site Down: A toggle field (Applicable or Not Applicable) that the person creating the ticket sets when the fault involves a hub site.
2. Number of Affected Child Sites: A field that appears only when Hub Site Down is set to Applicable, capturing how many child sites are currently impacted.
3. Hub Site Name: A free-text field, also conditional on Hub Site Down being Applicable, recording the name of the hub site.

These three fields, configured with display conditions so the second and third only appear when the first is set to Applicable, give every downstream system exactly what it needs. Notifications can include the hub site name and child site count. Workflows can branch on whether Hub Site Down is Applicable to trigger escalation paths. Reports can filter on this field to segment hub outages from standard faults.

The elegance of this pattern is that it adds no friction to standard single-site tickets. If Hub Site Down is Not Applicable, the extra fields never appear and the form stays clean. The additional detail is only asked for when it is actually relevant.

‍

Setting It Up in Clappia

The following steps assume you already have a corrective maintenance ticketing app in Clappia. If you are starting from scratch, build the core fault ticketing form first, covering site selection, fault classification, and contact auto-population from a Site Master Data app. The hub impact fields sit inside the Details section of that form.

Step 1: Add the Hub Site Down Toggle

Inside the Details section of your ticketing app, add a Single Selector block labelled 'Hub Site Down'. Add two options: 'Applicable' and 'Not Applicable'. This field should always be visible whenever a fault ticket is being created. Set its default value to 'Not Applicable' so the form behaves correctly for the majority of single-site tickets without requiring any action from the user.

Step 2: Add the Conditional Child Site Count Field

Add a Single Selector block labelled 'Number of Affected Child Sites'. Populate it with numeric options covering the range your network supports, for example 1 through 50. Then set a display condition on this field:

{Hub Site Down} = "Applicable"

This means the field only appears when the person creating the ticket has confirmed it is a hub outage. For all other tickets it is invisible, keeping the form uncluttered.

Step 3: Add the Hub Site Name Field

Add a Single Line Text block labelled 'Hub Site Name'. Set the same display condition:

{Hub Site Down} = "Applicable"

The person creating the ticket types the name of the hub site here. This name will be pulled into Telegram messages, emails, and reports exactly as entered, so encourage your NOC team to use consistent naming that matches your site master records.

Step 4: Update Your Notification Templates

With the three fields in place, the next step is to make sure they appear in every notification that goes out when a hub outage ticket is created. Open the workflow for your ticketing app (Design App > Workflows) and find the Telegram and email notification actions that fire when Status = 'Ticket Created'.

Update the message body to include the hub site fields. A practical Telegram message for a hub outage looks like this:

New Fault Ticket: {Ticket Number}

Site: {Site Name} | {Site ID}

Circle: {Circle} | District: {District}

Alarm: {Alarm Reported} | Fault Type: {Fault Type}

Fault Start: {Fault Start Date} {Fault Start Time}

ETR: {Estimated Time of Resolution}

Hub Site Down: {Hub Site Down}

Hub Site Name: {Hub Site Name}

Child Sites Affected: {Number of Affected Child Sites}

For standard single-site tickets where Hub Site Down is 'Not Applicable', the hub fields will simply show 'Not Applicable' and a blank value. If you want to suppress them entirely for non-hub tickets, you can use an IF formula to build the message string conditionally. In Clappia's formula editor, type @ to insert field variables, and Clappia wraps the selected field name in curly brackets automatically. A conditional message line would look like this:

IF({Hub Site Down}="Applicable", "Hub Site: " & {Hub Site Name} & " | Child Sites: " & {Number of Affected Child Sites}, "")

Fields used: Hub Site Down, Hub Site Name, Number of Affected Child Sites.

What the formula does: Returns the hub site detail string when the outage is a hub incident, and returns an empty string for all other tickets.

What the recipient sees: For hub outages, the message includes a line like 'Hub Site: North Tower | Child Sites: 12'. For standard faults, that line is absent entirely.

‍

Routing Hub Outages to a Priority Queue

Knowing that a hub site is down is only useful if the right people find out and respond faster than they would for a standard fault. In Clappia, you achieve this by adding a parallel workflow branch that fires specifically when Hub Site Down is Applicable.

Inside your New Submission Flow workflow, after the standard notification actions, add a new condition branch with the following check:

{Hub Site Down} = "Applicable"

Under this branch, configure additional notification actions that go beyond the standard fault notification list. Depending on your organisation, these might include:

• Additional Telegram messages: Send directly to the Circle Head, O&M Head, and TOC Head, even if they are already on the standard notification list. Hub outages warrant a direct message rather than relying on someone to forward the standard alert up the chain.
• A priority email to a separate inbox: Many operations teams maintain a distinct high-priority or major-incident mailbox that triggers a different response protocol. Route hub outage tickets here in addition to the standard NOC inbox.
• An escalation flag: If your organisation uses a separate major incident management process, this branch can trigger the initial notification for that process.

This approach means that the standard notification path handles every fault, while the hub outage branch fires additional escalations on top of it when the situation warrants it. You are not replacing the standard flow; you are extending it for the cases that need more attention.

The goal of priority routing is not to create noise for everyone. It is to ensure that the people who need to make resource decisions, not just the people who need to respond on the ground, are informed immediately when the impact scale changes.

‍

Auto-Assignment and Status Progression for Hub Outages

The standard auto-assignment pattern in a Clappia fault ticketing workflow uses a Wait node followed by an Edit Submission action that updates the ticket status from 'Ticket Created' to 'Ticket Assigned'. For hub outages, you may want to shorten that wait or skip it entirely, since the priority is getting someone moving immediately rather than waiting for the standard acknowledgement window to expire.

Inside the hub outage condition branch, you can add an Edit Submission action with a shorter wait, or no wait at all, that advances the ticket status immediately. You can also set the assigned team or individual differently for hub outages if your organisation has a dedicated major incident response team separate from the standard field force.

The key point is that the workflow lets you treat hub outages as a distinct operational category without creating a separate app or a separate ticket type. The same form, the same submission, the same ticket number. Just a different response path triggered by a single field value.

‍

Segmenting Hub Outages in Reports

The third area where the hub impact fields deliver value is in reporting. If you build your operations reports, whether inside Clappia's analytics view or by exporting submissions to an external BI tool, you can now filter and group by the Hub Site Down field to answer questions that were previously impossible to answer cleanly:

‍

None of these questions require any additional data entry from your field teams. The hub impact fields capture the necessary information at ticket creation time, and your reporting layer can slice it however is most useful. This is the kind of insight that typically requires a separate major incident management system; here it comes from three fields in your existing ticketing app.

What the Complete Hub Outage Workflow Looks Like

To make this concrete, here is the end-to-end sequence from ticket creation to resolution for a hub-and-spoke outage managed through this system:

1. A NOC engineer or field technician opens the ticketing app and selects the affected site using the site picker. Site metadata, including contacts and location details, auto-populates from the Site Master Data app.
2. The engineer sets Hub Site Down to 'Applicable', selects the number of affected child sites from the dropdown, and types the hub site name. The fault start time, alarm type, fault category, and estimated resolution time are also filled in.
3. The ticket is saved. The on-save workflow fires immediately.
4. Standard Telegram alerts go to the Technician, Engineer, Cluster Lead, Network Engineer, TOC Lead, TOC Head, Circle Head, and O&M Head. Each message includes the hub site name and child site count so every recipient knows the full scope from the first notification.
5. A standard email goes to the central NOC inbox.
6. The hub outage condition branch fires in parallel. Additional Telegram messages go directly to the Circle Head and O&M Head. A priority email goes to the major incident inbox.
7. The auto-assignment branch runs with a shortened wait and updates the ticket status to 'Ticket Assigned' within seconds.
8. The response team dispatches with the correct resources for a multi-site incident. They have the hub site name, child site count, and ETR from the notification before they leave.
9. As the incident progresses, the ticket status is updated through the lifecycle: Accepted, Active, Restored.
10. On resolution, the engineer fills in the fault close time, root cause analysis, action taken, and attaches before and after photos. The app calculates total repair time automatically. The ticket moves to Closed.

‍

Practical Tips for Field Teams

The system only works as well as the data that goes into it. A hub outage that is logged as a standard single-site fault because the person creating the ticket did not set Hub Site Down correctly will not trigger the priority routing and will not appear in hub outage reports. A few practical habits make a significant difference:

‍

Access, Permissions, and Mobile Use

For hub outage management specifically, getting the access configuration right matters more than in standard ticketing scenarios, because more people need visibility at different levels.

• Field engineers and NOC staff: Standard user access with the ability to create and update tickets. They do not need to see workflow configuration or analytics.
• Cluster leads and regional managers: View access to all submissions in their region so they can monitor active hub outages without needing to wait for someone to forward a status update.
• Operations heads and NOC leads: Admin-level view access so they can see the full ticket list, filter by Hub Site Down, and track resolution progress across regions.

The Clappia mobile app on Android and iOS is the primary interface for field engineers who are on site during a hub outage. The offline mode is particularly important here: if the hub site is down, the local network infrastructure that the field team relies on for connectivity may also be degraded. Offline mode allows them to log updates and close the ticket even without a signal, with the submission syncing and notifications firing once connectivity is restored.

‍

Conclusion

Hub-and-spoke outages are structurally different from single-site faults, and your ticketing system should reflect that. Three conditional fields, Hub Site Down, Number of Affected Child Sites, and Hub Site Name, are all it takes to give your notifications, dispatch decisions, and reports the context they need to treat hub outages as the priority incidents they are.

The pattern described in this article adds minimal complexity to your existing ticketing form while delivering a significant improvement in how hub outages are detected, communicated, and resolved. Field teams set one additional field when logging a hub incident. Everything else, the broader notifications, the priority routing, the segmented reports, follows automatically from that single input.

If you are already running a Clappia-based fault ticketing system, adding this pattern is a matter of hours, not days. If you are building a ticketing system from scratch, building the hub impact fields in from the start is far easier than retrofitting them later when your NOC team starts asking why the reports cannot distinguish between a site that affected one location and one that affected twenty.