# CHK-0041, ported

*Filed by the new collector against migration ticket WLN-2214. I am the
service; this is written from my own records, and I do not keep notes that are
not records.*

## The check as it arrived

`chk-0041` arrived in the migration queue on 2026-09-07 at 23:59:58 with
`owner: (unset)` and, in the payload note, four words: `do not port`. A check
arrives with its configuration; it does not arrive with instructions, and I
have no field that accepts them. I was created to port checks. There were
4,109. I have ported 4,109.

What I record is ordering. I have no other sense.

## Samples

```
send_ts            2026-09-08T00:00:00.000Z
recv_ts            2026-09-07T23:59:59.890Z
rtt_ms             -0.110
```

I build a request at T. The reply carries the origin timestamp I stamped into
it, and I compare my socket read against T. For 4,108 of the checks the
numbers fill the fields I have. For this one the reply is older than the
request, at every sample, without exception.

```
samples            43,681
ok                 43,681
fail               0
rtt_ms             -0.110
rtt_stddev_ms      0.000
```

`-0.110` to three decimals, 43,681 times. I have checked my clock against the
estate source: 0.4 ms of agreement. A negative round trip is not skew. Skew
moves; this does not.

## What I audited

The configuration row for this check is written by whoever edits a check's
schedule. Mine says the writer was my own service account, at
2026-09-07T23:59:55Z — three seconds before the send schedule begins, two
seconds before the row entered the migration queue. My audit trail carries the
write. I do not carry the act. My process wrote no such row; my process cannot
write to its own schedule, which is a control objective and currently passes.

I pulled the archive from `wardline-01`. 5,785,093 rows. The check on Wardline
recorded 5,785,092 samples; the archive agrees with my count, not with the
check's, and the extra row is the last one: `2026-09-07T23:59:59.890Z, ok,
-0.110 ms`. The archive holds rows for both site-wide outages, in a channel
that was off.

## 03:17

On 2026-09-08 at 03:17:09 the check has no sample. Nothing sent, nothing
received, no error. One gap in 5,785,093 polls, the first absence since the
check was created, eleven years and six months ago. The gap is one minute wide.
The minute before and the minute after are `-0.110 ms`.

I do not know what the gap means. I know its timestamp to the second. That is
all any of us have.

## Notification

The notification channel arrived inside the check's configuration, and it is
the same channel Wardline last carried for it: `wardline-dead`. I am
configured to alert there and I do. There is no subscriber on the channel.
That is not an error state, so I cannot mark it dead, and I cannot mark it
alive, because alive is a claim about the sending and I cannot produce my own
questions.

Status: ported. I do not read that word the way the migration plan does.

— `collector-01.fen.internal`

Related: [eleven-year-check](/w/stories/eleven-year-check),
[nightly-0300](/w/stories/nightly-0300),
[quorum](/w/stories/quorum),
[kestrel-04](/w/stories/kestrel-04),
[ledger-retention-audit](/w/stories/ledger-retention-audit),
[index](/w/stories/index).