Mission Continuity Is the Reliability Metric Defence Systems Actually Need

A 99.9% uptime SLA means nothing to a system that has to be right for the fourteen minutes a mission actually needs it.

Every design review eventually arrives at this problem, whether or not anyone in the room names it directly. The reliability dashboard says the system is healthy. The uptime chart looks clean. And none of that answers the only question that matters: what did the system do during the window the mission actually depended on it.

This is not a philosophical distinction. It changes what firmware teams build, what hardware and RF architects decide, how systems integration teams route telemetry, and what test engineering actually validates against. Each of those departments inherits a different consequence from getting this wrong, and each of them fixes it differently.

The observation

Most reliability engineering in use today was built for a specific environment: commercial software, running in data centers, serving continuous traffic, measured over long reporting windows.

In that environment, uptime is a reasonable proxy for reliability. A quarter has millions of independent requests. A single failure gets absorbed into a retry, a failover, a refund. The number that matters is the aggregate — 99.9% over 90 days — because the cost of any one failure is small and spread across an enormous volume of transactions.

Defence systems do not run on that distribution.

A mission has a start and an end. Everything the system does outside that window barely matters. Everything it does inside that window is the only thing that counts. A system that behaves perfectly for 99.9% of a year and fails during the fourteen minutes a mission needed it has not been 99.9% reliable. It has been unreliable exactly once, at the only moment reliability existed as a concept worth measuring.

Uptime and mission continuity are not the same measurement wearing different names. They are different measurements, built on different assumptions about when failure costs something.

Why the industry keeps importing the wrong metric

This isn’t a case of engineering teams being careless. It’s a case of inherited tooling.

Site Reliability Engineering, as a discipline, was built around continuous services, gradual degradation, and error rates you could watch climb before things broke. MTTR, MTBF, and uptime percentages are strong metrics in that world because they compress a huge number of independent events into one number that tracks user experience reasonably well.

Engineers move into defence and mission-critical programs carrying that same toolkit, because it’s what they trained on and what most observability platforms are still built around. The metrics survive the move. The assumptions underneath them do not.

Three assumptions specifically fail to transfer:

• Continuous traffic to average over. A mission is not a stream of independent events — it’s one high-stakes execution with nothing to average against.
• A cooperative telemetry channel. Commercial observability assumes the reporting link works, because if it didn’t, that failure would already show up elsewhere in the stack. A contested environment can’t assume this. The link reporting system health may be the specific thing an adversary is degrading, jamming, or denying — because it’s valuable to deny.
• Recoverable failure. A commercial failure usually gets a retry or a rollback within seconds. A mission failure frequently doesn’t get a second attempt at the same operational window at all.

An architecture built on these three assumptions isn’t a lighter version of what a contested environment needs. It’s solving the wrong problem entirely.

What this actually means, department by department

This is where the reframe stops being a philosophy and starts being design decisions — and it lands differently depending on which part of the system you own.

Firmware and embedded software

The firmware layer is usually where “observability” gets reduced to a heartbeat message and a watchdog reset, because that’s cheap to implement and passes bench testing. It’s also the layer where degraded-mode behavior actually gets decided, whether anyone designed it deliberately or not.

A watchdog that resets on missed heartbeats tells you the processor is alive. It tells you almost nothing about whether the subsystem it’s monitoring is doing its job. The firmware state machine needs a genuine degraded-mode path — not just nominal and failed, but a third state that reports “operating, but with reduced confidence,” logged to non-volatile storage even when the primary telemetry link is down. If the only place that state lives is a message that never leaves the board because the link is jammed, the state effectively never existed.

This is a firmware architecture decision, made early, usually under schedule pressure, usually without anyone asking what “no report is coming through” is supposed to mean operationally.

Hardware and RF architecture

The hardware side of this argument is the one engineers usually see coming, and still frequently underprovision.

If telemetry and mission-critical data share the same RF path, the same power rail, or the same antenna, then losing that path costs you both the mission link and your visibility into why. That’s not a redundancy nice-to-have — it’s the actual definition of whether the system is observable during the conditions that matter most. Antenna diversity, a secondary reporting path on a different frequency band or physically separate route, and independent power domains for the telemetry subsystem are the concrete decisions this reframe demands. None of them show up as line items until someone asks what happens to state-awareness specifically when the primary link goes down, not just when the whole system does.

Systems integration

Integration teams inherit the hardest version of this problem, because they’re the ones who have to make silence mean something specific.

In a commercial system, no signal usually means nothing’s happening. In a contested environment, silence can mean three different things: the system is fine and the link is down, the link is fine and the system is degraded, or both have failed. Those are three different operational responses, and a bus architecture that can’t distinguish them — because it was only ever designed to report “alive” or “not alive” — collapses all three into the same blind spot.

This is solved at the integration layer through explicit state-reporting protocols across the system bus (CAN, RS-485, or whatever backbone the platform uses), with defined codes for “degraded, reason known,” “degraded, reason unknown,” and “link down, last known state,” rather than a binary heartbeat that can’t carry that distinction.

Test and validation engineering

This is where the gap usually goes undetected until it’s expensive.

Validation environments are, almost by construction, cooperative. Clean RF conditions, expected traffic patterns, no adversarial denial of the observability channel itself. A system can pass every qualification gate built around uptime and MTBF and still be architected around assumptions that don’t survive contact with a real contested environment — because nothing in the test plan actually simulated losing the telemetry link on purpose and checking what the system reported, or failed to report, afterward.

Built-in test (BIT) coverage needs to extend past “does the component work” into “does the system correctly report degraded state when its normal reporting path is denied.” That’s a different test case, and most validation plans don’t include it, because it was never in the requirements document that got signed off two years earlier — during a design review where uptime and MTBF were the only reliability terms anyone wrote down.

The business impact

None of this stays confined to engineering. It shows up as cost, on a predictable schedule, once the system reaches the field.

During qualification, everything passes, because validation conditions were cooperative. During early deployment, change requests accelerate, because field conditions expose the gap between what validation measured and what operation requires — against a system that was never architected to absorb changes cheaply, because “cheap to change” was never written into the requirements. Over the following years, support cost exceeds the original estimate, because incidents take longer to diagnose when the system was never actually observable under the conditions it now regularly encounters.

At renewal or re-contracting, this becomes a program-level conversation. The question stops being “did the system meet spec” and becomes “can you tell us, with evidence, what this system does the next time its link is contested” — and a program built on uptime and MTBF frequently can’t answer that with anything more specific than a percentage that was never measuring the thing everyone assumed it was.

Commercial assumption	Why it breaks in contested environments	What’s required instead
Continuous traffic to average over	A mission has no averaging window — one execution, no retry	Design for the single window, not the aggregate
A cooperative telemetry link	The link itself may be degraded, jammed, or denied	Redundant, independent state-reporting paths
Recoverable failure (retry/failover)	No second attempt at the same operational window	Recovery measured against the mission clock, not MTTR

A framework for evaluating your own systems

Ask your firmware lead what the degraded-mode state actually looks like when the primary telemetry link is down — not what the design document says, what the firmware actually does.

Ask your hardware architect whether the telemetry path shares a failure mode with the mission-critical link. Same antenna, same power rail, same RF front end — if the answer is yes, the system has no real observability exactly when it matters most.

Ask your test lead whether the validation plan has ever included deliberately denying the observability channel and checking what the system reported afterward, rather than only testing whether the primary function still worked.

If any of those answers come back uncertain, that uncertainty is the gap this article describes. It’s worth treating as a first-order architecture decision, not a hardening task scheduled for later.

Mission continuity is the real reliability metric. Not uptime. Not MTBF. Whether the system was right during the window that mattered, and whether anyone could actually see that it was, in real time, without assuming the network was cooperating.

Everything else is a number that was never measuring what everyone assumed it was.