Skip to content

Keep the monitor box alive

Nerthus.Core (until cutover). This page describes the frozen system that runs today and is deleted at cutover. Replaced by: not yet written.

The fleet's monitor runs on a free box that is deleted after three months without a login. This page is the rhythm that keeps it, and the one thing on this site that must not quietly stop being true.

The rule, and the clock

From https://frog.mikr.us, verbatim:

Serwery, na które nikt nie logował się przez 3 miesiące, są usuwane.

clock started 2026-08-04 — the day the box was provisioned and last logged into by a person
assumed expiry 2026-11-02 — 90 days, the shorter reading of "3 miesiące", so the error is early
last comfortable month to act October

One place owns that date. It is $script:NerthusRestorationClockStartedUtc in Nerthus.Infra.Restoration/RestorationCommon.ps1; both the login script and the watch read it from there, and a test asserts neither carries a literal of its own. This page and 16-czuwanie/08-idle-deletion.md point at that constant rather than restating it. If you ever change it, change it there.

What nobody can check

Whether an automated login counts. The provider's page does not define "logował się" — it says nothing about SSH versus a panel login, and nothing about per-account versus per-server.

And nothing on our side can reconcile. /var/log/wtmp is zero bytes on that image and nothing writes to it, so last returns nothing and always will. Whatever the provider counts, it counts on their side.

Their API cannot answer it either. None of the thirteen documented api.mikr.us endpoints reports a last login, an idle counter, or a deletion countdown. /stats reports uptime, which is the wrong quantity twice over: a box up for ninety days with nobody logging in is exactly the box the rule deletes.

So the machine login below is a hedge, and the human login is the control. That is a decision, recorded in 75-frog-keepalive/HUMAN.md as H75.1(a), and not an accident of what got built.

What runs without anybody remembering

A GitLab schedule on Nerthus.Infra.Restoration, on the 3rd of each month at 06:00 UTC, opens one session on the box:

  • It logs in as keepalive, a dedicated non-root account — not in wheel, no sudoers entry, and demonstrably unable to become root.
  • Its key runs one forced command and nothing else: /usr/local/bin/nerthus-keepalive-session, root-owned and 0555, which prints a username, a UTC instant and wtmp's size. Whatever command the caller sends is ignored.
  • A PTY is allocated. That is the deliberate half of the trade: the strongest containment would be no-pty, and a forced command with no terminal is the least plausible thing to count as somebody logging in. The containment is the command; the PTY is what makes the session look like a login.
  • The result appends to keepalive.log, and the exit code is the job's status. A failed session reddens the job.

Monthly rather than quarterly because the clock is ninety days: monthly gives two chances to notice a failure before the box is at risk, and a quarterly job that fails once is a deleted box.

What notices when it stops

A job that does not run produces no red. So a second job, keepalive:watch, runs on every pipeline — merge requests included — and measures the age of the last successful session:

verdict exit means
recent 0 a session opened inside the bound. Not "healthy" — that word is refused, because it cannot be known
stale 2 the last success is over 45 days old, or the box is inside its last 30 days
blind 3 there is no log, or nothing in it ever succeeded. Not the same as nothing to report

45 days is derived, not chosen, and the derivation is worth having because it settles a tension the brief left implicit. A monthly job on the 3rd produces gaps of 28 to 31 days, so any bound at or under ~35 days reddens on a healthy cadence — a false alarm every month, which is the fastest way to teach somebody to ignore this row. Above that, the constraint is the ninety-day clock: at 45 days, one run has demonstrably been missed and there are still 45 days and one more monthly attempt before the box is at risk.

So the consequence appears within a month of the first missed run, not within a month of whatever caused it. Concretely, with a last success on 2026-08-20 and the September run missed, the watch reads (over the real log, at those dates):

date verdict since last success to deletion
2026-09-15 recent 25 d 48 d
2026-10-05 recent 45 d 28 d
2026-10-10 stale 50 d 23 d
2026-10-20 stale 60 d 13 d

Three weeks of warning before the box is at risk, and none of it spent on false alarms.

It needs no credential, no network and no key, which is why it can run anywhere — a check that ran only on the schedule it watches would go quiet at exactly the moment that schedule stopped. And it measures the absence of a success rather than asking whether the schedule object still exists, so a deleted schedule, a disabled one, an archived project and a runner that never picks the job up are one measurement instead of four checks.

Run it by hand any time:

pwsh -File ./Invoke-NerthusKeepaliveWatch.ps1
[keepalive-watch] 1 attempt(s), 1 success(es)
[keepalive-watch] last session opened 2026-08-04T16:57:44Z — 16 day(s) ago
[keepalive-watch] 73 day(s) to the ASSUMED deletion date 2026-11-02 (clock started 2026-08-04)
VERDICT recent — a session opened inside the bound. That is what was measured; it is not «healthy».

Two dates and the gap between them. Either number alone is one nobody can act on.

The monthly human login — this does not go away

On the first working day of each month, alongside Check the quota:

pwsh -File ./Confirm-NerthusRestorationLogin.ps1

It opens an interactive session as frog, appends to the same log, and refuses to print a green summary — it says a session opened and states plainly that this is not a confirmation the provider counted it.

Do not retire this because the automated logs look green

A month of green rows is evidence the script ran. It is not evidence the provider counted it, and there is nothing on either side that could turn one into the other. Retiring the human login is only defensible if the provider is asked directly and answers — the question is one sentence, and it is the only thing that would turn this hedge into a control.

If the box is deleted anyway

A bounded consequence, not an outage. The monitor's document stops being served, the Worker's gate stops seeing a fresh sweptUtc, and within 40 minutes the Worker resumes sweeping at the same 15-minute cadence and posts its resume notice. The fleet stays watched.

What is lost: the second vantage on host reachability, and the Worker starts spending KV again — about 192 reads and 96 writes a day against a free cap of 1,000 writes.

What it costs to rebuild: there is one free FROG per person, so the account cannot simply take another. Standing a replacement up is Nerthus.Infra.Restoration's installer against a new box, which is an afternoon — provided there is a box to install onto.

See also