Skip to content

Muppy 18.83.0

Released 2026-09-07.

A host says when it stopped being patched

A host patches itself on its own schedule, and Muppy had no view of whether that was still happening. A System Upgrade tab on the Host form now carries what the machine itself knows: the number of Pending Updates, the Last Successful Refresh of its package lists, the Last Upgrade Run, and a System Upgrade badge reading Ok, Stale or Not collected. Click Update System Upgrade State to ask a host. The Hosts list offers Days Since Upgrade and Pending Upd. as optional columns, so the whole park reads in one screen.

Stale means the host has not refreshed its package lists successfully for longer than the threshold — seven days by default. A retired repository, a severed network, a disabled unattended-upgrades: different causes, one conclusion, which is that this machine is no longer being patched.

Not collected is not Ok

A host nobody has asked yet reads Not collected — never a number, never green. Read it as a question, not as an answer: a park you have not measured otherwise looks like one in perfect health.

Provisioning also survives a dead repository. A package-list refresh that fails only because a third-party repository has been retired no longer aborts an App Server's provisioning. A failure that names a distribution host — a held lock, a full disk, a dead resolver — still stops it, because there the package lists really are stale.

What you have to do. Collect the state on your hosts once, then read the badge. Two settings sit under Settings ▸ Muppy Core:

  • System Upgrade Stale After (days) — the threshold, seven by default. A healthy host never exceeds a day or two, so a week of silence is unambiguous breakage rather than a slow day. An empty, mistyped or negative value falls back on the default instead of being honoured.
  • Distribution Repository Hosts — the hosts that serve your distribution's packages. If you serve packages from a mirror of your own, name it here, so a failure on it is treated as real breakage rather than as a third-party repository going away.

A Traefik server says when its DNS directives no longer match their source

A Traefik server holds a frozen copy of the DNS provider credentials it uses to answer Let's Encrypt's DNS-01 challenge. Rename the instance or rotate a token and that copy becomes wrong in silence: renewals fail and nothing shows it until a certificate expires. Two indicators now sit on the Traefik server form:

  • ENV Directives — Up to date, Drifted, or Unknown when the directives could have come from either of two sources and Muppy will not guess. It compares what the server holds against what its source produces today, and it is searchable, so one filter finds every drifted server.
  • Target ENV Directives Not Deployed — the directives were reloaded but the server has not been reconfigured since, so the host still runs the old ones.

Two indicators rather than one, because loading alone would turn a true alarm into a false all-clear: Load "DNS Provider ENV Directives" from Domain clears the drift and raises not deployed, so the form never goes quiet between the two gestures.

The HTTPRequest tab of a DNS Domain now also explains the chain it configures: which consumer reaches which endpoint, which toggle commands which one, and that what the tab displays is the HTTPRequest flavour of the variables — the values actually handed to Traefik are the ones in the Configs tab.

Read the indicator once on the servers you already run

The verdict is computed on existing servers too. Open the list of Traefik servers and read ENV Directives: on every Drifted one, load the directives from their source, then Reconfigure. A server reading Unknown is one whose directives could equally have come from a domain or from a provider authorization — reload them from the right one to settle it.

The whole chain, and how to read a certificate that will not issue: Let's Encrypt Certificates (DNS-01).

A health check can watch any Muppy record, not only Kubernetes objects

The check type that reads Muppy's own rows was wired onto Kubernetes objects, although nothing in it touched Kubernetes. It becomes Muppy Internal: point it at a shared saved filter on any Muppy model, write a processor, and the next subject you want watched costs a saved search rather than a development.

What you gain. Results are much smaller and much easier to read — the stored trace of the shipped certificate check went from about twenty thousand characters to five hundred. A result also carries Processing Duration (s), which tells you where a slow check spends its time.

What you have to do. Nothing. The cert-manager monitoring on your clusters becomes one use of the general type, watches the same clusters as before, and its existing results are carried over.

How to point a check at your own records: Watching Muppy's own records.

kubectl, helm and docker report an absence as an absence

Collecting the version of a tool that is not installed used to produce the wrong fact. An absent kubectl was reported as present with an unreadable version — the nominal answer on every App Server that does not install it — and helm returned one opaque line whatever had gone wrong. The three collectors now behave alike: an absence is reported as an absence and at information level, because it is a fact and not a failure; a tool that is present and answers badly is reported separately, as itself.

kubectl's presence is also decided without contacting a cluster, so an installed kubectl on a host with no cluster configured is no longer read as missing. Installing and removing it no longer refuses to run on an Ubuntu release it has not been told about: a newer release is handled like the most recent one it knows.

What you have to do. Nothing, beyond collecting the facts again on hosts where KUBECTL_ACTIVE_VERSION, HELM_ACTIVE_VERSION or DOCKER_ACTIVE_VERSION looks wrong.