By the Creation Networks AV Engineering Team
A Q-SYS Core runs the whole system. It mixes the audio, routes the video, runs the control logic, and serves the touch panels. In most rooms, that is fine. In a courtroom, an emergency operations center, a stadium paging system, or a sanctuary streaming a live service, a single processor is a single point of failure.
Q-SYS Core redundancy fixes that by putting a second, identical Core in hot standby. This post walks through how Q-SYS Core redundancy actually behaves, what it costs, how to design the network around it, and why a redundant pair still needs someone watching it. We wrote it from QSC's own documentation and from commissioning these systems in the field.
What Q-SYS Core redundancy actually does
Q-SYS Core redundancy pairs two identical Core processors in one design. One Core is Primary and the other is Backup. At startup the Primary is Active and the Backup sits in Standby.
The Standby Core is not idle. It checks the health of the Active Core continuously. It also keeps a synced copy of control settings, snapshots, and event schedules. Audio files on the Primary are copied to the Backup automatically.
When the Standby Core detects a fault on the Active Core, it takes over audio streaming and control of every peripheral and becomes the new Active Core. A fault can be a power loss, a crashed runtime, or a Core that drops off the network.
Here is the part most marketing skips. Failover is fast, but it is not silent. QSC's documentation puts an automatic failover at about 10 seconds. A manual switch, using the Go Active control, takes about 3 seconds. Peripherals mute during the switch and unmute when the new Core is in control.
QSC also notes that failover time has not been tested on very large systems. On every redundant job we commission, we measure the real failover time and hand the number to the client in writing.
How a Q-SYS failover plays out, step by step
Normal operation. The Primary Core runs the system. The Backup Core monitors it, mirrors its state, and stays in contact with the peripherals so it is ready to take over.
The failure. The Backup detects the fault, takes control of the peripherals, and goes Active. Audio mutes for roughly 10 seconds and then comes back on the Backup.
After the failure. The system does not switch back to the Primary on its own. QSC designed it this way to avoid a second audio gap. When the Primary comes back online, it waits in Standby until someone presses Go Active during a quiet window.
That last point matters more than it sounds. After a failover, the building is still running, but it is now running on one Core with no backup behind it. If nobody notices, the next failure takes the system down. We come back to this in the monitoring section below.
What carries over in a failover, and what does not
| System element | Behavior during failover |
|---|---|
| Design file | Loaded on both Cores at deploy time. Both Cores must be online when you deploy. |
| Control values, snapshots, event schedules | Synced continuously. The Backup picks up where the Primary left off. |
| Audio and media files | Copied from Primary to Backup automatically. File names containing # or % cause sync faults. |
| Read-only controls | Not synced. |
| Lua scripts and plugins | Run only on the Active Core. They start up again on the new Active Core. |
| USB, POTS lines, RS-232, GPIO and analog outputs on the Core itself | Not redundant. Critical outputs belong on network peripherals. |
| Calls in progress | Drop. The softphone re-registers from the new Active Core. |
Core redundancy versus network redundancy
These two features get confused constantly. They protect against different failures, and the best systems use both.
Network redundancy sends duplicate Q-LAN audio streams over two fully separate networks, called LAN A and LAN B. If a switch, cable, or port fails on one network, audio keeps flowing on the other. QSC states there is no failover time and no interruption to the audio stream. It only protects devices that are set as network redundant and physically wired to both networks.
Core redundancy protects against the processor itself failing. It does not prevent the roughly 10-second gap.
If the requirement is "no audible interruption, ever," only network redundancy delivers that, and only for network-path failures. If the requirement is "the system must keep running even if a Core dies," you need Core redundancy. Mission-critical systems need both, plus monitoring.
| Application | Typical Core | Core redundancy | Network redundancy (LAN A / LAN B) | Monitoring |
|---|---|---|---|---|
| Life-safety paging and mass notification | Server Core X20r pair (redundant power supplies) | Yes | Yes, on separate switch stacks | 24/7, fastest response tier |
| Government EOC, courtroom, council chamber | Server Core X10 pair, or Core 510i pair | Yes | Yes | 24/7, fastest response tier |
| Large worship or performing-arts venue | Core 510i or Server Core X10 pair | Yes, when downtime during an event is unacceptable | Yes | 24/7 |
| Higher-ed central Core serving many rooms | Server Core X10 or X20r pair | Yes, because one Core failure takes out every room it serves | Recommended | 24/7, building-level |
| Single conference room or classroom | Core Nano or Core 8 Flex | Usually not justified | Optional | 24/7 monitoring plus a spare |
The Server Core X10 and X20r replaced the Core 610, which QSC discontinued in May 2025. QSC documents LAN A / LAN B network redundancy for the X Class. Before we quote a redundant X10 or X20r Core pair, we get written confirmation from QSC for the exact design and firmware.
For government work, see our government AV solutions. For campuses, see our education AV integration page.
Which Q-SYS Cores support redundancy
QSC states that all Q-SYS Core processors can run redundant, as long as both Cores are the same model. In the current line that covers the QSC Core Nano, QSC Core 8 Flex, QSC Core 24f, and QSC Core 510i. For large systems, the QSC Server Core X10 and QSC Server Core X20r replace the discontinued Core 610.
There are a few exceptions and rules:
- The NV-32-H running in Core mode does not support Core redundancy.
- QSC does not document redundancy for the software-based vCore. We treat it as unsupported until QSC confirms otherwise in writing.
- QSC's general redundancy statement was written before the X Class. We confirm Primary/Backup support for an X10 or X20r pair with QSC in writing before we quote one.
- X Class Server Cores have no onboard GPIO, analog I/O, or USB, so every input and output sits on network peripherals. That suits a redundant design, because nothing critical is tied to one box.
- Both Cores need identical hardware. Two Core 510i units with different I/O cards are not supported, and they fault after a failover.
- Media drive upgrades must match on both Cores.
- Both Cores should run the same firmware. Never deploy or upgrade with only one Core online.
You can browse the full Q-SYS line in our Q-SYS collection.
Licensing: budget for two of everything
This is where redundant quotes most often go wrong. A redundant pair does not share one set of licenses. Every feature license your design uses has to be installed on both the Primary and the Backup.
That includes the Scripting Engine, UCI Deployment, Microsoft Teams Room licensing, and software-based Dante. QSC is specific about Dante: each Core needs its own unique Dante license. If a license lives only on the Primary, the Backup cannot run that feature after a failover. If you're running older software, our short FAQ on Scripting and UCI licensing when rolling a Core back to 9.x covers the free entitlement IDs.
For a Core 510i pair, that means two SLQSE-510-P Scripting Engine licenses and two SLQUD-510-P UCI Deployment licenses, not one of each. The Core 24f and the X Class Server Cores include scripting and UCI deployment, so a pair of those needs no separate licenses for those two features.
There is one place you save. Q-SYS Reflect counts a redundant pair as one system, so the pair needs only one Reflect System license. QSC does not sell a separate redundancy license.
Designing the network for a redundant pair
A redundant Core pair is only as reliable as the network between the two Cores. These are the rules we follow on every job:
- Put LAN A and LAN B on separate subnets and separate switches. Never bridge them.
- Configure a default gateway on one LAN only, normally LAN A. Gateways on both LANs cause communication faults.
- Give each Core its own static IP address and its own hostname.
- Use untagged access ports for Q-SYS devices.
- Set QoS so PTP timing traffic is in the highest-priority queue and audio is in the next queue. Do not rely on auto-QoS.
- Run IGMP snooping with one querier per VLAN, and turn off Energy Efficient Ethernet on Q-SYS ports.
- Allow the Core-to-Core redundancy traffic through any firewall between the two Cores.
- Put the two Cores in separate racks, on separate circuits, and on separate UPS units. Do the same for the LAN A and LAN B switch stacks.
One more trap. The Q-SYS Core Redundancy network service is off by default. Setting a Core to redundant in Q-SYS Designer does not turn it on. It has to be enabled by hand on both Cores in Core Manager.
What goes wrong with redundant Q-SYS systems
Most redundancy problems we see are configuration problems, not hardware failures.
Licenses only on the Primary. The system fails over and then loses its scripts, touch panels, or Dante.
The redundancy service never enabled. The design says redundant, but the Cores cannot talk to each other.
Mismatched hardware. Different I/O cards or different media drives break the pair.
Control systems pointed at one IP address. Q-SYS does not provide a shared virtual IP for a redundant pair. Each Core keeps its own address. A third-party control system, or a device that only accepts commands from one IP, goes silent after a failover. Control clients need to know both Core addresses and follow whichever Core is Active.
Crossed network failures. If LAN A fails on one Core and LAN B fails on the other, the pair can lose the ability to switch. We test for this during commissioning.
Firmware drift. QSC has fixed several redundancy bugs across recent releases, including Control Links that did not reconnect after failover in 9.12 and a softphone double-registration issue fixed in 10.1. We check the release notes for the exact firmware before every deploy, and we keep mission-critical sites on QSC's long-term support release.
Why a redundant pair still needs monitoring
Redundancy keeps the system running through a failure. It does not tell anyone the failure happened.
After an automatic failover, the system runs on the Backup Core. The Primary sits in Standby or stays offline. Nothing switches back until a person acts. From the room, everything looks normal. In reality, the building has lost its safety net, and the next fault takes the system down.
That is the gap our Clarity Remote Monitoring service closes. Clarity is powered by Q-SYS Reflect, which already counts a redundant pair as one system. Our engineers watch both Cores 24/7. When a pair fails over, a Core drops to a compromised or fault state, or audio files stop syncing, we see it and contact you. Our complete Clarity guide covers what gets monitored and how fast we respond.
Clarity comes in three tiers, and each tier sets how fast we reach you:
- Clarity Pro contacts you in under 15 minutes and includes a quarterly report on uptime, usage, and end-of-life risks. This is the tier we recommend for redundant, mission-critical systems.
- Clarity Plus contacts you in under 30 minutes and adds occupancy analytics.
- Clarity Basic contacts you in under 60 minutes.
A central Core pair serving a whole building or campus usually fits building-level monitoring, such as Clarity Building Remote Monitoring for 21 to 50 devices. You can compare every package in the Clarity Remote Monitoring collection.
Clarity is a standalone service, so no maintenance contract is required. If you also want scheduled preventive visits and a guaranteed on-site response time, add a Creation Care maintenance plan. For fully managed AV with stocked critical spares, see AVAILS managed AV services, or read how the three support programs compare.
Commissioning and long-term support
A redundant system is only proven once it has failed over in front of you. Our commissioning process for every redundant Q-SYS system includes:
- A manual failover with Go Active, timed and recorded.
- A hard failover by pulling power on the Active Core, timed and recorded.
- Network isolation tests on LAN A and LAN B.
- Checks after each failover: audio paths, paging priorities, schedules, touch panels, third-party control, the softphone, and Dante subscriptions.
- A recovery test to confirm the failed Core comes back in Standby and does not take control on its own.
The client receives a signed test log, the measured failover times, license backups for both Cores, and a written procedure for switching back to the Primary. We recommend repeating the failover test every quarter during a maintenance window.
Design, programming, installation, commissioning, and monitoring work best as one relationship. A redundant system that nobody tests or watches slowly drifts back into a single point of failure. Our control and DSP programming team handles Q-SYS design and commissioning end to end.
More Q-SYS guides
Core redundancy is one piece of a larger Q-SYS design. These guides cover the rest:
- Q-SYS Ecosystem Benefits — why one software platform for audio, video, and control changes how rooms are designed and supported.
- Q-SYS vs. Biamp vs. Crestron DSP — how the three platforms compare for real rooms.
- How to Choose QSC Systems for Enterprise AV — matching Cores, I/O, and licensing to the project.
- Q-SYS NC Series Network Cameras — the native camera line behind VisionSuite.
- Q-SYS VisionSuite Certified for Microsoft Teams — AI presenter tracking and camera switching for Teams Rooms.
- Q-SYS in Airports — emergency alerts, paging, and gate control in transportation hubs.
Q-SYS Core redundancy FAQ
How long does Q-SYS Core failover take?
An automatic Q-SYS Core failover takes about 10 seconds, according to QSC's documentation, and a manual switch with Go Active takes about 3 seconds. Audio on the peripherals mutes during the switch and returns once the Backup Core is in control. QSC notes that failover time has not been tested on very large systems, so we measure and record the real number during commissioning.
Do both Q-SYS Cores in a redundant pair need licenses?
Yes, every feature license must be installed on both the Primary and the Backup Core. That includes Scripting Engine, UCI Deployment, Microsoft Teams Room, and software-based Dante licenses. QSC requires a unique Dante license for each Core. The one exception is Q-SYS Reflect, which needs only one System license for the redundant pair.
Does a redundant Q-SYS system switch back to the Primary Core automatically?
No, a Q-SYS redundant pair does not fail back automatically. QSC built it this way to avoid a second audio interruption. When the Primary Core recovers, it waits in Standby until someone presses Go Active on it. We recommend switching back during a scheduled maintenance window, and monitoring the pair so you know when a failover has happened.
Which Q-SYS Cores support redundancy?
All Q-SYS Core processors support redundancy when two identical models are paired, according to QSC. In the current line that includes the Core Nano, Core 8 Flex, Core 24f, and Core 510i. The Core 610 was discontinued in May 2025; its replacements, the Server Core X10 and X20r, are confirmed with QSC in writing before we quote a redundant pair. The NV-32-H in Core mode does not support redundancy. Both Cores need matching I/O cards, matching media drives, and the same firmware.
What is the difference between Q-SYS Core redundancy and network redundancy?
Core redundancy protects against a Core processor failing, while network redundancy protects against a switch, cable, or port failing. Network redundancy sends duplicate audio over LAN A and LAN B with no interruption. Core redundancy switches to a Backup Core with a gap of about 10 seconds. Mission-critical systems should use both.
How do you monitor a redundant Q-SYS system?
Q-SYS Reflect monitors a redundant Q-SYS pair as one system and reports the status of both Cores. Creation Networks' Clarity Remote Monitoring uses Reflect to watch both Cores 24/7. Our engineers contact you when a failover happens or a Core faults. Clarity Pro contacts you in under 15 minutes.
Creation Networks, Inc. — nationwide commercial AV integrator, CTS-D certified, headquartered in Incline Village, NV with a California office in Concord. Design, engineering, programming, installation, and support from a single point of contact since 2006. Call 888-230-3661 or email sales@creationnetworks.net.
Get Started
Let's Talk About a Redundant Q-SYS Design
Tell us about your system and what can't go down. A CTS-D engineer reviews your design and recommends the right Core, network, and monitoring setup, usually within one business day.
