Skip to main content

Lusser's Law and Applicability

Terry Critchley

Availability Probabilities

Application availability depends on the availability of other elements in a system, for example, network, server, operating system and so on, which support the application. Concentrating solely on the availability of any one block will not produce optimum availability of the application for the end user.

In the following diagram, a "linear" or "non-redundant" configuration of elements supporting the user application is shown. In vendor engineering publications, these elements are referred to as "blocks," although other publications may refer to them as "components."

It is evident that if any block in the series configuration fails, the user loses the use of the application. The application is as available as the weakest link in the chain, or so it would appear.

The following figure is a schematic showing a linear chain of blocks, henceforth known as non-redundant blocks or blocks in series. It is easy to see that the failure of any block in the chain will cause a failure of the service to the end user.

There are, of course, other blocks in the chain, such as operating system, middleware and so on (not shown here) but the principle is the same. A single component whose failure causes overall failure is called a single point of failure or SpoF.


The equations above demonstrate that a series of blocks is weaker than its weakest component simply because of the multiplication of several factors, all of which are less than or equal to 1.

Lusser's Law

Lusser's Law is a prediction of reliability named after Robert Lusser (He worked on Wernher von Braun's US rocketry program post-WW2) . It states that the reliability of a series system (of our "blocks") is equal to the product of the reliability of its component subsystems, if their failure modes are known to be statistically independent. This is what we see in the above diagram. The law can be stated as follows:


This lays to rest the theory that a chain is as strong as its weakest link, the thinking at the time. Lusser's Law deals with the reality of this situation.

Next in this document we will discuss using components in parallel and how to make the assessment of availability more IT-specific and not just deal with anonymous blocks or components which might represent anything in a reliability context - valves, pipes etc.

Part of availability management is the examination of the service failure points in the configuration between application and user, assess their impact on service availability and design round them. Obviously there are cost implications to going over the top in design, especially in the cases below.

Effect of Redundant Blocks on Availability

The discussion so far has dealt with linear chains of blocks (blocks in series, to use an electrical analogy), where the whole chain is weaker than its weakest link – Lusser's Law.
To carry this analogy further, it is possible to use blocks in parallel to increase the availability of the chain, assuming that one block can take over from a failed block, assuming that the blocks fail independently. The following diagram illustrates this for two blocks:


These blocks might be NICs, disks, server or other parts of a working system. The general case for 'n' parallel blocks is shown below, together with the equations for availability and non-availability probabilities.

Parallel (Redundant) Components

The next figure illustrates components configured in parallel as opposed to in series as we have seen already. The mathematics of these configurations is similar to Lusser's mathematics except we deal with 'unreliability' instead of 'reliability' entities in the math.

The basic premise in these calculations is that if the probability of being available is P, then the probability of not being available is N where;

N = (1-P) and P = (1-N)

since the total availability of being available or not available is 1. In reality, a system will consist of several sets of redundant components, for example disks, servers, network card, lines and so on. These will feed into each other, possibly mixed with single components.

The figure below shows the general case of "n" blocks in a parallel configuration. This might represent one set of components for a subsystem such as a RAID configuration or set of network interface cards (NICs). Such a configuration can be difficult to handle mathematically so a 'reduction' technique is usually employed.


Two Parallel Blocks: Example

Picture two components in parallel, one with availability probability Pa and the other Pb. The probability of both blocks being unavailable, that is, the chain is broken, is:


This assumes the blocks have different availability characteristics, Pa and Pb..If they were the same, say Pa = Pb = P, then the probability that both are not available is given by the relationship:


which is essentially a variation of Lusser's Law using the non-availability probabilities as multipliers instead of availability probabilities. The probability that 'n' redundant blocks are unavailable is (1 - P)n and the probability that they are all available is given by the relationship [1- (1 - P)n ]

As an example, consider two parallel blocks, each with an availability of 99.5 %. The probability that both are unavailable is:

N = (1 - 0.995) x (1 - 0.9995) = 0.000025

Hence its availability (compared with the availability of a single non-redundant case of 99.5%) is:

A(%)=(1-N) x 100=(1-0.000025) x 100%=99.999975%

The knowledge of each value of "P" and some mathematical skills would be needed to solve the problem of service availability for a combination of serial and parallel service blocks, which is often the case in real life. The book High Availability IT Services covers this latter case.

The Latest

Technology leaders across the federal landscape are facing, and will continue to face, an uphill battle when it comes to fortifying their digital environments against hostile and persistent threat actors. On one hand, they are being asked to push digital transformation ... On the other hand, they are facing the fiscal uncertainty of continuing resolutions (CR) and government shutdowns looming near and far. In the face of these challenges, CIOs, CTOs, and CISOs must figure out how to modernize legacy systems and infrastructure while doing more with less and still defending against external and internal threats ...

Reliability is no longer proven by uptime alone, according to the The SRE Report 2026 from LogicMonitor. In the AI era, it is experienced through speed, consistency, and user trust, and increasingly judged by business impact. As digital services grow more complex and AI systems move into production, traditional monitoring approaches are struggling to keep pace, increasing the need for AI-first observability that spans applications, infrastructure, and the Internet ...

If AI is the engine of a modern organization, then data engineering is the road system beneath it. You can build the most powerful engine in the world, but without paved roads, traffic signals, and bridges that can support its weight, it will stall. In many enterprises, the engine is ready. The roads are not ...

In the world of digital-first business, there is no tolerance for service outages. Businesses know that outages are the quickest way to lose money and customers. For smaller organizations, unplanned downtime could even force the business to close ... A new study from PagerDuty, The State of AI-First Operations, reveals that companies actively incorporating AI into operations now view operational resilience as a growth driver rather than a cost center. But how are they achieving it? ...

In live financial environments, capital markets software cannot pause for rebuilds. New capabilities are introduced as stacked technology layers to meet evolving demands while systems remain active, data keeps moving, and controls stay intact. AI is no exception, and its opportunities are significant: accelerated decision cycles, compressed manual workflows, and more effective operations across complex environments. The constraint isn't the models themselves, but the architectural environments they enter ...

Like most digital transformation shifts, organizations often prioritize productivity and leave security and observability to keep pace. This usually translates to both the mass implementation of new technology and fragmented monitoring and observability (M&O) tooling. In the era of AI and varied cloud architecture, a disparate observability function can be dangerous. IT teams will lack a complete picture of their IT environment, making it harder to diagnose issues while slowing down mean time to resolve (MTTR). In fact, according to recent data from the SolarWinds State of Monitoring & Observability Report, 77% of IT personnel said the lack of visibility across their on-prem and cloud architecture was an issue ...

In MEAN TIME TO INSIGHT Episode 23, Shamus McGillicuddy, VP of Research, Network Infrastructure and Operations, at EMA discusses the NetOps labor shortage ... 

Technology management is evolving, and in turn, so is the scope of FinOps. The FinOps Foundation recently updated their mission statement from "advancing the people who manage the value of cloud" to "advancing the people who manage the value of technology." This seemingly small change solidifies a larger evolution: FinOps practitioners have organically expanded to be focused on more than just cloud cost optimization. Today, FinOps teams are largely — and quickly — expanding their job descriptions, evolving into a critical function for managing the full value of technology ...

Enterprises are under pressure to scale AI quickly. Yet despite considerable investment, adoption continues to stall. One of the most overlooked reasons is vendor sprawl ... In reality, no organization deliberately sets out to create sprawling vendor ecosystems. More often, complexity accumulates over time through well-intentioned initiatives, such as enterprise-wide digital transformation efforts, point solutions, or decentralized sourcing strategies ...

Nearly every conversation about AI eventually circles back to compute. GPUs dominate the headlines while cloud platforms compete for workloads and model benchmarks drive investment decisions. But underneath that noise, a quieter infrastructure challenge is taking shape. The real bottleneck in enterprise AI is not processing power, it is the ability to store, manage and retrieve the relentless volumes of data that AI systems generate, consume and multiply ...

Lusser's Law and Applicability

Terry Critchley

Availability Probabilities

Application availability depends on the availability of other elements in a system, for example, network, server, operating system and so on, which support the application. Concentrating solely on the availability of any one block will not produce optimum availability of the application for the end user.

In the following diagram, a "linear" or "non-redundant" configuration of elements supporting the user application is shown. In vendor engineering publications, these elements are referred to as "blocks," although other publications may refer to them as "components."

It is evident that if any block in the series configuration fails, the user loses the use of the application. The application is as available as the weakest link in the chain, or so it would appear.

The following figure is a schematic showing a linear chain of blocks, henceforth known as non-redundant blocks or blocks in series. It is easy to see that the failure of any block in the chain will cause a failure of the service to the end user.

There are, of course, other blocks in the chain, such as operating system, middleware and so on (not shown here) but the principle is the same. A single component whose failure causes overall failure is called a single point of failure or SpoF.


The equations above demonstrate that a series of blocks is weaker than its weakest component simply because of the multiplication of several factors, all of which are less than or equal to 1.

Lusser's Law

Lusser's Law is a prediction of reliability named after Robert Lusser (He worked on Wernher von Braun's US rocketry program post-WW2) . It states that the reliability of a series system (of our "blocks") is equal to the product of the reliability of its component subsystems, if their failure modes are known to be statistically independent. This is what we see in the above diagram. The law can be stated as follows:


This lays to rest the theory that a chain is as strong as its weakest link, the thinking at the time. Lusser's Law deals with the reality of this situation.

Next in this document we will discuss using components in parallel and how to make the assessment of availability more IT-specific and not just deal with anonymous blocks or components which might represent anything in a reliability context - valves, pipes etc.

Part of availability management is the examination of the service failure points in the configuration between application and user, assess their impact on service availability and design round them. Obviously there are cost implications to going over the top in design, especially in the cases below.

Effect of Redundant Blocks on Availability

The discussion so far has dealt with linear chains of blocks (blocks in series, to use an electrical analogy), where the whole chain is weaker than its weakest link – Lusser's Law.
To carry this analogy further, it is possible to use blocks in parallel to increase the availability of the chain, assuming that one block can take over from a failed block, assuming that the blocks fail independently. The following diagram illustrates this for two blocks:


These blocks might be NICs, disks, server or other parts of a working system. The general case for 'n' parallel blocks is shown below, together with the equations for availability and non-availability probabilities.

Parallel (Redundant) Components

The next figure illustrates components configured in parallel as opposed to in series as we have seen already. The mathematics of these configurations is similar to Lusser's mathematics except we deal with 'unreliability' instead of 'reliability' entities in the math.

The basic premise in these calculations is that if the probability of being available is P, then the probability of not being available is N where;

N = (1-P) and P = (1-N)

since the total availability of being available or not available is 1. In reality, a system will consist of several sets of redundant components, for example disks, servers, network card, lines and so on. These will feed into each other, possibly mixed with single components.

The figure below shows the general case of "n" blocks in a parallel configuration. This might represent one set of components for a subsystem such as a RAID configuration or set of network interface cards (NICs). Such a configuration can be difficult to handle mathematically so a 'reduction' technique is usually employed.


Two Parallel Blocks: Example

Picture two components in parallel, one with availability probability Pa and the other Pb. The probability of both blocks being unavailable, that is, the chain is broken, is:


This assumes the blocks have different availability characteristics, Pa and Pb..If they were the same, say Pa = Pb = P, then the probability that both are not available is given by the relationship:


which is essentially a variation of Lusser's Law using the non-availability probabilities as multipliers instead of availability probabilities. The probability that 'n' redundant blocks are unavailable is (1 - P)n and the probability that they are all available is given by the relationship [1- (1 - P)n ]

As an example, consider two parallel blocks, each with an availability of 99.5 %. The probability that both are unavailable is:

N = (1 - 0.995) x (1 - 0.9995) = 0.000025

Hence its availability (compared with the availability of a single non-redundant case of 99.5%) is:

A(%)=(1-N) x 100=(1-0.000025) x 100%=99.999975%

The knowledge of each value of "P" and some mathematical skills would be needed to solve the problem of service availability for a combination of serial and parallel service blocks, which is often the case in real life. The book High Availability IT Services covers this latter case.

The Latest

Technology leaders across the federal landscape are facing, and will continue to face, an uphill battle when it comes to fortifying their digital environments against hostile and persistent threat actors. On one hand, they are being asked to push digital transformation ... On the other hand, they are facing the fiscal uncertainty of continuing resolutions (CR) and government shutdowns looming near and far. In the face of these challenges, CIOs, CTOs, and CISOs must figure out how to modernize legacy systems and infrastructure while doing more with less and still defending against external and internal threats ...

Reliability is no longer proven by uptime alone, according to the The SRE Report 2026 from LogicMonitor. In the AI era, it is experienced through speed, consistency, and user trust, and increasingly judged by business impact. As digital services grow more complex and AI systems move into production, traditional monitoring approaches are struggling to keep pace, increasing the need for AI-first observability that spans applications, infrastructure, and the Internet ...

If AI is the engine of a modern organization, then data engineering is the road system beneath it. You can build the most powerful engine in the world, but without paved roads, traffic signals, and bridges that can support its weight, it will stall. In many enterprises, the engine is ready. The roads are not ...

In the world of digital-first business, there is no tolerance for service outages. Businesses know that outages are the quickest way to lose money and customers. For smaller organizations, unplanned downtime could even force the business to close ... A new study from PagerDuty, The State of AI-First Operations, reveals that companies actively incorporating AI into operations now view operational resilience as a growth driver rather than a cost center. But how are they achieving it? ...

In live financial environments, capital markets software cannot pause for rebuilds. New capabilities are introduced as stacked technology layers to meet evolving demands while systems remain active, data keeps moving, and controls stay intact. AI is no exception, and its opportunities are significant: accelerated decision cycles, compressed manual workflows, and more effective operations across complex environments. The constraint isn't the models themselves, but the architectural environments they enter ...

Like most digital transformation shifts, organizations often prioritize productivity and leave security and observability to keep pace. This usually translates to both the mass implementation of new technology and fragmented monitoring and observability (M&O) tooling. In the era of AI and varied cloud architecture, a disparate observability function can be dangerous. IT teams will lack a complete picture of their IT environment, making it harder to diagnose issues while slowing down mean time to resolve (MTTR). In fact, according to recent data from the SolarWinds State of Monitoring & Observability Report, 77% of IT personnel said the lack of visibility across their on-prem and cloud architecture was an issue ...

In MEAN TIME TO INSIGHT Episode 23, Shamus McGillicuddy, VP of Research, Network Infrastructure and Operations, at EMA discusses the NetOps labor shortage ... 

Technology management is evolving, and in turn, so is the scope of FinOps. The FinOps Foundation recently updated their mission statement from "advancing the people who manage the value of cloud" to "advancing the people who manage the value of technology." This seemingly small change solidifies a larger evolution: FinOps practitioners have organically expanded to be focused on more than just cloud cost optimization. Today, FinOps teams are largely — and quickly — expanding their job descriptions, evolving into a critical function for managing the full value of technology ...

Enterprises are under pressure to scale AI quickly. Yet despite considerable investment, adoption continues to stall. One of the most overlooked reasons is vendor sprawl ... In reality, no organization deliberately sets out to create sprawling vendor ecosystems. More often, complexity accumulates over time through well-intentioned initiatives, such as enterprise-wide digital transformation efforts, point solutions, or decentralized sourcing strategies ...

Nearly every conversation about AI eventually circles back to compute. GPUs dominate the headlines while cloud platforms compete for workloads and model benchmarks drive investment decisions. But underneath that noise, a quieter infrastructure challenge is taking shape. The real bottleneck in enterprise AI is not processing power, it is the ability to store, manage and retrieve the relentless volumes of data that AI systems generate, consume and multiply ...