Beyond Uptime

For decades, technology reliability in financial services has largely been measured through uptime, with 99.999% availability, or “five nines,” considered the gold standard.

Was the core available? Was online banking accessible? Were employees able to connect? Did the network remain operational?

Those measurements still matter. But in an increasingly interconnected technology environment, uptime alone is no longer enough to define resilience.

Credit unions depend on core platforms, networks, cloud services, telecommunications providers, cybersecurity tools, third parties, APIs, and internal infrastructure. Even when individual components are widely available, one failed dependency or ineffective recovery process can disrupt the service.

The better question is no longer simply, “How do we prevent an outage?” It is, “When something fails, how quickly and confidently can we continue operating?”

Reliability Can Create False Confidence

Modern technology environments are remarkably reliable. That creates an unintended problem; backup systems may go years without real-world use.

A redundant internet connection can exist for years without meaningful testing. A disaster recovery environment may pass an annual exercise even as the assumptions behind it change. A critical application may have layers of redundancy, yet one upstream dependency can interrupt service.

Documentation may say systems will failover automatically. Architecture diagrams may show redundant paths. Vendors may advertise high availability.

Resilience is not proven by architecture diagrams. It is proven by performance under stress.

True resilience requires validating that people, processes, and technology will behave as intended when operations are disrupted.

Design for What Happens When Systems Degrade

Technology leaders should design for failure, not exclusively to prevent it.

That does not mean accepting outages. It means acknowledging that hardware can fail, telecommunications carriers and cloud providers can experience disruptions, software can contain defects, and people can make mistakes.

The goal is to keep failures from becoming organizational crises.

Teams should understand how systems operate both normally and when degraded.

Questions Every Leader Should Ask

For every critical service, leaders should be able to answer:

• What dependencies must be available for this service to function?
• What happens if one of those dependencies fails?
• Is failover automatic, manual, or somewhere in between?
• How will we know that failover actually occurred?
• What business functions remain available during the disruption?
• What decisions would employees need to make?
• When was the recovery process last tested under realistic conditions?

These questions move resilience beyond architecture and establish it as an operational capability. They also distinguish redundancy from resilience.

Redundancy means having another option. Resilience means knowing the other option will work when you need it.

When the Backup Is There but the Recovery Is Not

Consider a credit union or technology provider with two telecommunications circuits at a critical location.

On paper, the architecture appears resilient: a primary connection, an independent secondary provider, and equipment configured for failover.

Then the primary carrier experiences an outage.

The secondary circuit is healthy, but traffic does not transition properly.

Perhaps a routing condition was not detected correctly. Maybe monitoring showed paths as available while the end-to-end service was not functioning. Or a configuration changed and the backup path had not been retested.

That distinction matters: infrastructure can appear healthy while the business service dependent on it is effectively unavailable.

The organization had redundancy, but not the resilience it expected.

For credit unions, the impact extends beyond technology. Members may be unable to access digital banking, complete transactions, or reach support teams. Operational resilience protects member trust as much as it protects systems.

The most important outcome is not simply restoring service. It is learning from the gap between how the architecture was designed and how it actually behaved.

A mature response asks:

• Why did the failure not trigger the expected recovery?
• Could monitoring have detected the condition sooner?
• Could employees have identified the issue faster?
• Can failover testing be performed more frequently?
• Are there additional dependencies that were not previously understood?

Those lessons should become engineering improvements, monitoring changes, updated procedures, and future tests. That cycle of design, test, observe, and improve is the foundation of operational resilience.

Resilience Is an Organizational Capability

Credit union executives should resist treating resilience as solely an IT responsibility.

Technology teams operate infrastructure, but business leaders determine which services are critical and how much disruption the organization can tolerate.

A two-hour outage means something very different for an internal reporting application than for digital banking, card processing, or access to the core.

Technology and business leaders should establish shared expectations around recovery priorities, acceptable degradation, and business continuity.

Organizations should evaluate concentration risk. Services that appear independent may rely on the same cloud provider, carrier, identity platform, or vendor. Understanding these dependencies is essential to resilience planning.

Disaster recovery and business continuity programs are most valuable when they challenge assumptions rather than simply prove a recovery plan exists.

• What happens if the primary site is available, but telecommunications are not?
• What happens if technology is operational, but employees cannot access the building?
• What happens if a major vendor is unavailable?
• What happens if multiple failures occur simultaneously?

Real incidents rarely follow the clean sequence illustrated in a recovery plan.

Organizations that practice making decisions under imperfect conditions are better prepared when those conditions become real.

Moving Beyond “Five Nines”

Five nines will always matter. Members expect reliable technology, and credit unions should hold themselves and partners to high standards.

But resilience requires something more.

It requires understanding dependencies, validating failover paths, improving monitoring, exercising recovery procedures, and testing assumptions.

It also requires measuring more than uptime: how quickly incidents are detected, how long recovery takes, how frequently failover processes are tested, and how consistently recovery objectives are achieved.

Leaders should celebrate long periods of uptime.

They should also ask the uncomfortable question:

If this system failed tomorrow, are we certain we know what happens next?

The organizations that can answer that question with confidence are not simply reliable.

Uptime measures whether technology is available. Resilience measures whether the organization can continue serving members when it is not.

Mitch Ryan, CCUE, is Vice President of Information Systems at Synergent, where he leads technology teams supporting credit unions and their critical operations. With more than a decade of experience spanning credit union leadership and technology services, Mitch brings a practical perspective to technology strategy, operational resilience, and organizational leadership. An alumnus of Thomas College and a graduate of the University of Wisconsin School of Business, he is passionate about coaching people to reach their full potential, strengthening operational resilience, and helping credit unions navigate an increasingly complex technology landscape.