---
title: "Self-healing is not a feature, it is a different architecture"
url: "https://demertis.com/blog/self-healing-is-not-a-feature"
description: "Bolting recovery onto a system that was designed to be repaired by people produces automation that fails in more interesting ways, not fewer."
---

# Self-healing is not a feature, it is a different architecture

August 21, 2026·3 min read·Demertis

Self-healing appears on a lot of roadmaps as a feature to be added later — after the system works, once there is time. It does not work that way. A system designed on the assumption that a person will eventually look at it has that assumption in every layer, and adding recovery on top of it produces something that fails in more interesting ways rather than fewer.

## The assumption hiding everywhere

A system built for human repair treats failure as an exception: something outside normal operation, which stops the process and hands control to somebody else. Everything follows from that. Errors are raised rather than handled. State is left where it was so a person can inspect it. Logs are written for a reader. Recovery is a runbook, which is to say a document, which is to say not code.

Automating that means writing a program to read the situation a human would have read, and that program is doing the hardest part of the job with the least information.

## What the other architecture assumes

Degradation is a normal state, not an exception. The system is always somewhere on a scale between healthy and failed, and moving along it is ordinary operation rather than an incident.

This changes concrete things:

**Health is continuous, not a check.** Not a probe returning up or down at intervals, but a signal that has a value at all times, so movement is visible before it crosses a threshold.

**Every action has a defined inverse.** Not a rollback plan in a document — a reverse path in the code, tested by being used, because recovery that only runs during disasters only gets tested during disasters.

**State is reconstructible.** The system can rebuild where it is from a durable record rather than inferring it from whatever survived in memory. This is the expensive one and it is the one that makes the rest possible.

**Repair is subject to the same supervision as work.** A repair action is an action. It gets recorded, bounded and interrupted the same way, because a self-healing system that can modify its own supervision is not self-healing — it is unsupervised.

## The failure mode worth naming

The dangerous version is a system that repairs itself well enough that nobody notices it is doing it constantly. Errors get absorbed, metrics stay green, and a slow structural problem hides behind a fast recovery loop until the recovery itself becomes the load.

The defence is boring: repair is logged as prominently as failure, repair frequency is a first-class metric, and any increase in it is treated as a fault in its own right. A system that heals more often this month than last is telling you something, and it is not that it is getting better.

## Why the distinction matters here

An autonomous operation cannot page anybody. There is no escalation path, no on-call rota, no human at the end who will notice that something has been quietly retrying for six hours. Every recovery either happens inside the loop or does not happen at all.

That is not a more advanced version of ordinary operations. It is a different architecture, and it has to be there from the start — which is exactly why this part of the programme is being built before anything is connected to anything that matters.

-   self-healing
-   reliability
-   control loops
-   operations

## Keep reading

-   [The last human in the loop is a signature](https://demertis.com/blog/the-last-human-in-the-loop-is-a-signature)
-   [Can a machine own anything?](https://demertis.com/blog/can-a-machine-own-anything)