Sluicio v0.11.64

A health check can now alert when a metric goes silent

A metric check only ever fired on a value it measured. That is the right default - plenty of metrics report only when something happens, and alerting on their silence would page constantly - but it leaves a gap exactly where it matters most.

A synthetic HTTP probe exists to keep reporting. When the collector or the probe itself dies, the series simply stops, and to the evaluator "the endpoint is fine" and "nothing is watching the endpoint any more" looked identical.

Metric checks now offer "Also alert if this metric stops reporting", in both the health-check editor and the metrics alert builder. A window with no data at all counts as unhealthy.

How it behaves

• Off by default, and off changes nothing. Existing checks behave exactly as before.
• It starts watching once the check has seen data at least once. Saving a check before its exporter is deployed will not alert you - the condition is "stops reporting", and something that never started has not stopped. The trade-off is that a metric which never arrives at all stays quiet.
• The alert never quotes a value it did not measure. It reads "queue.depth stopped reporting (no data for 5m)", and notifications show the value as n/a rather than 0. Zero is a plausible reading for most metrics, so showing it would be indistinguishable from a real measurement.
• On a check broken down by attribute, this detects the metric going silent entirely. A single attribute value disappearing cannot be detected, because there is no record of which values are meant to exist - only which ones reported.

Two related fixes

• An open alert whose metric went quiet used to resolve with "recovered to 0.00", claiming a recovery that was never measured. It now says the metric stopped reporting.
• A check that moves between "breaching the threshold" and "stopped reporting" while its alert stays open now updates its summary, instead of keeping whichever condition first opened it.

Detecting absence elsewhere

This completes the picture across the three signals. Log checks already have it - set the comparison to fewer than and zero matching logs is the breach, which expresses "no heartbeat log in the last hour". Traces have the low-traffic check, which fires precisely because a service went quiet.

Sluicio v0.11.63

Dashboards put what is broken at the top

Cards were ordered by traffic volume for integrations, and by whatever order they happened to be pinned for systems. Neither has anything to do with whether something needs attention, so the one unhealthy card could sit below a screenful of healthy, busy ones — the opposite of what the page is for.

Integrations and systems now sort worst health first, then by name:

unhealthy → errors → ok → quiet

Name as the tiebreak also means a board with nothing wrong holds still, instead of reshuffling every ten seconds as traffic moves between cards.

Notes

• On a board holding both kinds, the two are ranked on the same scale. An integration and a system that report the same health sit together, even though the two render that health with different coloured pips.
• Nothing you arranged is lost. Dashboards have never had a way to reorder cards, so card position was only ever the order things were added.
• On a "show every integration" dashboard, cards with a custom widget no longer jump to the front. Nothing on screen marked them out, so leading with them was arbitrary — they keep their widget and take their place in health order.

Sluicio v0.11.62

An internal test-suite fix. No product changes — nothing in this release alters how Sluicio behaves.

What changed

One end-to-end test created an integration, a group and a user with run-unique names and never removed them, so every suite run left an integration on the test cell permanently.

That cost compounds: the integrations endpoint prices per-integration traffic queries, so every other test polling that list got slower with each run, until unrelated tests began timing out on long-lived test cells. One had its time budget raised three times chasing the symptom.

With the cleanup in place, the integration count stays flat across runs, the suite runs in roughly a quarter of the time, and the failures that only appeared on a cell with history are gone.

Sluicio v0.11.61

A documentation and copy pass over the Paperless-ngx system type introduced in v0.11.60. No behaviour changes.

What changed

• The system type now links its documentation page: docs.sluicio.com/system-types/paperless-ngx.

• The prerequisite note explaining why traces can go missing has been corrected. It said the Celery prefork pool exports no telemetry. It does — a minimal reproduction shows plain prefork exporting every span. What actually loses spans is child recycling: Paperless pins worker_max_tasks_per_child = 1, so each worker is killed the moment its task returns, while the batch span processor is still holding that task's spans waiting on its flush interval. Nothing flushes on the way out, and no error or dropped-span counter reports it.

  The workaround is unchanged — run the consumer with --pool solo, which has no children to recycle — but the reason matters: the old wording would lead someone to conclude prefork is unusable with OpenTelemetry and give up concurrency everywhere, not just here.

• Template descriptions use plain hyphens rather than em dashes, so they render consistently wherever they are shown.

Sluicio v0.11.60

A dashboard can hold a system

Dashboards could pin integrations and services. Systems — the thing that has members, its own health checks, and its own rolled-up status — could not go on a board at all, even though they are peers of integrations everywhere else in the product.

They can now. edit dashboard offers add system, listing your systems with their member counts. The card shows the system's type, its health, and how many services it covers, and clicks through to the system.

Only integrations and systems

The old add system picker actually listed services flagged as a system. Wrong label, and off-model: this is an integration-centric product, and a board holds integrations and systems.

That picker is gone. Cards created by it are untouched — they still render and can still be removed, under a strip now labelled System services so the two never read alike. Nothing was converted or deleted: mapping a flagged service onto a system means guessing, and it may belong to none.

The card reports health, it does not guess

The card shows the status the server computes, which already folds in the checks bound to the system itself. A browser cannot see those checks, so anything recomputing health in the page calls a system with a firing check quiet — the failure fixed across four surfaces in v0.11.56–58. This card does not recompute.

Fixes

• The remove × on a system card did nothing outside edit mode. It was offered on every system card, but outside edit mode the page renders the saved dashboard while the button edited a draft — so the card sat there and nothing saved. It is now edit-mode only, matching the integration card.
• last could not be chosen when editing a health check. The health-check editor offered seven aggregation functions; the metrics builder offered nine. The two missing were last and age — and last is the only correct function for a point-in-time gauge, so a check on an HTTP status code could not be expressed at all, though the server has always accepted it and ships templates using it. Both pickers now share one list.
• Pinning a system from another organisation is refused at the API rather than accepted and rendered as a permanently blank card.
• A card whose system was deleted still renders, marked no longer exists, so it can be removed.

Also

Paperless-ngx is recognised as a system type, with monitoring templates and a documentation page at docs.sluicio.com/system-types/paperless-ngx.

Sluicio v0.11.59

Put a system on a dashboard

Dashboards could pin integrations and services. Systems — the thing that has members, its own health checks, and its own rollup status — could not go on a board at all, even though they are peers of integrations everywhere else in the product.

They can now. edit dashboard gains a second picker, add system entity, listing your systems with their member counts. The card shows the system's type, its health, and how many services it covers, and clicks through to the system.

Two kinds of system card, on purpose

The older add system picker is still there and still works. It pins a service that has been flagged as a system, keyed by its name. The new picker pins a system — a different object, with an id, several member services, and checks bound to itself.

Existing cards were left exactly as they are. Converting them would have meant guessing which system a flagged service belongs to, and it may belong to none. When a dashboard holds both, the older strip is labelled System services so the two stay distinguishable.

The card reports health, not a guess

The card shows the status the server computes, which already folds in the checks bound to the system itself. A browser cannot see those checks, so anything recomputing health in the page calls a system with a firing check quiet — the failure fixed across four surfaces in v0.11.56–58. This card does not recompute.

Also

• Pinning a system from another organisation is refused at the API rather than accepted and rendered as a permanently blank card.
• A card whose system was deleted still renders, marked no longer exists, so it can be removed. Previously an invisible card would have been unremovable.

Sluicio v0.11.58

Fixes a regression in v0.11.57: on a cell whose failing health checks are bound to systems, the Errors page counted them but showed nothing. Upgrade if you are on v0.11.57.

A firing system check now shows up everywhere it matters

v0.11.57 gave system-bound checks their own identity so they would stop being labelled "Org-wide" on the Errors page. They were then filed under a category the page did not yet recognise, so the rows disappeared — while the counter, which is computed separately, still reported them. The page said 3 failing checks above an empty list.

That is fixed, and so are three related places where the same signal went missing. On a cell whose only trouble was three firing system checks, the product previously said four different things at once:

	said	now
Errors page	"3" above an empty list	the three checks, grouped by system
Systems list	unhealthy	unhealthy
System detail	quiet	unhealthy
Dashboard	All clear	names the unhealthy system

• System detail reported no health at all, so the page fell back to "quiet" while the systems list — computing it properly — said unhealthy. Both now use the same calculation.
• The dashboard's "needs attention" only ever considered integrations, so a cell whose only trouble was unhealthy systems read All clear directly beside a tile saying 3 of 3 unhealthy. It now considers systems too and links to whichever it picks.

Underneath, sorting checks into the groups the Errors page renders is now deliberately exhaustive: anything it cannot place stays visible under Org-wide rather than vanishing. A check that fires and is never shown is the worst outcome this page has, so it is now impossible by construction rather than by remembering.

Sluicio v0.11.56

Multi-architecture images start here: every image now publishes linux/amd64 and linux/arm64 in one manifest.

Images now run natively on arm64

Sluicio published amd64 only, so Graviton, Ampere and Apple silicon either refused the image or ran it under emulation. Every image — cell-api, cell-ingest, controlplane, frontend and the demo seeder — now ships both architectures in a single manifest, so docker pull and helm install resolve the right one with no per-architecture tags and no chart changes.

Nothing about how you deploy changes. ghcr.io/sluicio/cell-api:v0.11.56 simply works on both.

A system watched only by its own health checks no longer reads "Quiet"

If a system's health is defined entirely by checks bound to it — with no member services, because one runtime emits several systems' telemetry and is told apart by attribute — the system reported Quiet, meaning nothing is watching it.

It was more than a label. A metric check on a system with no members never evaluated at all: the scope resolved to zero services and returned no data, so the check never fired, never resolved, and the system sat on "Quiet" while looking configured.

That behaviour was designed for integrations, whose membership is reconciled in the background — there, an empty set usually means "not ready yet". System membership is attached by hand, so empty is a deliberate choice, and often the correct one. Systems now evaluate such checks against the rule's own criteria; integrations are unchanged.

Two details worth knowing:

• Metric and log checks work on a memberless system, because each carries its own narrowing — a metric rule names a metric, a log rule sets a severity floor. The system page states this, since a metric check with no attribute filters then watches every service you can see.
• Response-time and low-traffic checks still need members. They carry no criteria of their own, so "unscoped" would mean the whole cell, and "p95 across everything" is not a statement about a system.

A passing check now reads ok; a firing one still reads unhealthy and outranks everything. An unhealthy member service still makes the system unhealthy regardless. "Quiet" now means what it says: nothing is watching.

Health checks on the same metric are told apart

Three checks on one metric that differed only by attribute filter and by what they governed rendered as three identical rows — same name, same condition, same badge, three "remove" buttons and no way to know which was which. New checks are named <metric> alert by default, so they all start out identical.

Each row now shows its attribute filters, and the service, integration or system whose health it defines — by name. Checks that only notify say so.

Sluicio v0.11.55

Includes a database migration (0077_alert_rule_system). It adds one nullable column and an index to alert_rules and runs automatically on start. No backfill, no rewrite of existing rows.

Health checks can now govern a system

A check could define the healthy state of a service or an integration. A system — a peer of both everywhere else in Sluicio — was the only one left out, and it is the one that matters most for infrastructure: "the Kafka cluster is healthy iff consumer lag < X" describes the cluster, not any one broker, and there was no way to say it.

Systems now take the same three check kinds everything else does — metric, log, and failed-trace / response-time / low-traffic:

• System → Health checks — the same card service and integration pages have. Add, edit and remove checks where they belong.
• Metrics explorer — the health-check target chooser gains A system alongside a service and an integration.

A firing system-bound check makes the system unhealthy on its own. Previously a system could only inherit health from its members, so "the cluster is unhealthy" depended on some individual broker also looking unhealthy — exactly the coupling a cluster-level check exists to avoid. Member rollup is unchanged and still applies.

The live "would fire" preview is scoped to the system's member services, so what you see while writing the check is what the saved check evaluates. A system with no members yet reads as no data rather than silently widening to every service in the cell, and previewing a system you have no access to returns nothing rather than aggregating services you cannot see.

Low-traffic checks got more accurate in the process. They could not previously tell "this scope produced no traffic" from "this scope contains nothing" — both counted as zero, and both fired. A system or integration with no member services would raise a traffic alert about an empty set. That case is now skipped. A named service with no traffic still fires: that is the dead-man's switch, and it is a different statement.

Choose a system's type instead of typing its key

Creating a system asked, in a browser prompt, for its type key — "e.g. rabbitmq, kafka, postgresql" — from memory. The key was stored exactly as typed and never checked against the catalog, so RabbitMQ, rabbit, or a stray trailing space all saved happily and then matched no type at all. The system quietly received no starter checks, no monitoring template and no documentation link, with nothing on screen to explain why.

The type is now picked from the real catalog, shown as RabbitMQ (rabbitmq) so the key is visible without having to be remembered, and searchable. The same picker replaces the free-text box when editing a system. A system whose stored key matches nothing — which existing ones may — now says so instead of presenting itself as a valid choice.

If your system is not in the catalog, you can add it without leaving the form. Give it a name and the key is derived for you (IBM MQ → ibm-mq), shown before saving. Detection prefixes and starter checks stay on the System types page, which the picker links to.

Creating a system is now a form rather than a chain of browser prompts: the name and type are visible together, it can be cancelled, and errors appear in the form instead of disappearing with the dialog.

Sluicio v0.11.54

Health checks can now govern an integration

A health check could be bound to a service or left org-wide. There was no way to say "this metric defines whether this integration is healthy" — even though the alert engine has been able to evaluate exactly that for some time. Every evaluator already honoured an integration scope; the only thing that ever restricted checks to services was the UI never offering the choice.

Two places now offer it:

• Metrics explorer — the health-check binding asks what the check governs: nothing, a service, or an integration. Picking an integration evaluates the check across that integration's member services.
• Integration → Settings — a Health checks card, the same one service pages have. Add, edit and remove metric, log and failed-trace checks where they belong, instead of creating them elsewhere and hoping they land in the right place. The Alert rules card below it now covers what it uniquely offers — which channels each rule notifies, and whether it is enabled.

The live "would fire" preview follows the same scope. Bind a check to an integration and the preview is computed over that integration's services, so the rehearsal matches the performance. Previously a preview of an integration-bound rule would have aggregated every visible service — a number the saved rule would never produce.

Two things it deliberately will not do: an integration whose service membership has not been reconciled yet reads as no data rather than silently widening to every service, and previewing an integration you have no access to returns nothing rather than aggregating services you cannot see.

Note for one-runtime-many-integrations setups (Node-RED, Camel, a shared iPaaS worker): an integration-bound check evaluates over the integration's member services. Where several integrations share one service, the check therefore covers all of them, not the one flow. The picker says so where you choose.

Dimensionless metrics no longer print a stray "1"

UCUM, which OpenTelemetry metric units follow, spells "dimensionless" as the unit 1. Sluicio rendered it literally, so a dimensionless metric read "CURRENT 99 1", "gauge · latest · 1", and "Current 99 > threshold 50 1" — a trailing digit that looks like a typo or a second number and tells you nothing either way. It is now omitted wherever a unit is shown.

Units that merely contain a 1 — m/s2, 10*3/min — are unaffected, as are annotation-form counts like {messages}, which do tell you what is being counted.

The split-by health-check preview counted the wrong thing

Breaking a check down by an attribute previewed as "Would fire for 1 http.url (of 1)", attaching the count to the attribute's name rather than to its values — and pluralising a key that is not a countable noun, so two breaching URLs read as "2 http.urls". It now reads "Would fire for 1 of 1 http.url value".