Local periodic synthetic journeys

A synthetic user needs a defined journey

The Foundations probe creates an account, submits a deposit twice with one idempotency key, then checks Ledger. That is an API-based synthetic journey, not a browser login simulation. The optional UI's mocked values must not be treated as backend verification.

Create fresh synthetic data once, then save it as a case for later checks. Periodic checks can read that case to confirm persistence and the read path without creating unlimited accounts. A read-only periodic check does not prove that new writes still work; retain an occasional manually initiated fresh journey as separate evidence.

Understand the Job underneath the schedule

A Deployment tries to keep a long-running process present. A Job runs work to completion and records success/failure; its retry and deadline settings affect what happens when a Pod fails. A CronJob creates Jobs at scheduled times. Its schedule is not an exactly-once business guarantee. A script that changes data must therefore tolerate repetition or use a durable idempotency mechanism.

For the local saved-case read, record the expected transaction ID and balance once. Each run asks whether that same result can still be read. This is cheap and repeatable, but deliberately omits the fresh-write path. A newly created account on every schedule would test more of the write path while accumulating more data and introducing side effects. Those are different designs, not interchangeable probe modes.

Work through a schedule: a Job starts at 12:00 and is still running at 12:02. With Forbid, this CronJob does not start a concurrent replacement at 12:02. If the host sleeps, the missing run is not a pass. If you set suspend: true while the 12:00 Job runs, that existing Job still needs observation or explicit cleanup. A deadline bounds running time; a history limit bounds retained finished Jobs; neither ensures the tested application is correct.

Before enabling any schedule, use the lab's initially suspended CronJob to create one manual Job. Confirm its target, saved case, completion state, and logs. Only then observe a small number of local scheduled runs and suspend it again.

Keep execution local and bounded

The module lab defines a Kubernetes CronJob only in kind-microbank-advanced, initially suspended. It calls a fixed local Service, disables proxies and redirects, has a deadline, avoids concurrent runs, and keeps limited Job history. Do not add it to cloud overlays or hosted GitHub Actions.

A CronJob schedule is best-effort; missed or duplicate scheduling can occur. Make checks idempotent and treat absent runs as missing evidence. concurrencyPolicy: Forbid applies to Jobs from that CronJob, not every job in the namespace. Suspending a CronJob does not stop an already-started Job.

Record both result and freshness

Keep timestamp, tested revision, case ID, duration, and result in local evidence. Do not put a transaction ID into a Prometheus series label. When the exercise ends, stop scheduling and inspect any remaining active Jobs before cleaning up.

Checkpoint: explain the difference between “last check passed,” “a check ran recently,” “new transactions work,” and “the canary candidate passed.” Each requires different evidence. The later release gate explicitly selects the candidate endpoint.

Checkpoint answer: “last passed” describes a result; “recent” needs a completion timestamp; “new writes work” needs a fresh journey; “candidate passed” needs candidate selection. Carry all four questions into the analysis lesson so the controller cannot accidentally promote on the wrong evidence.

Sources

Kubernetes CronJobs↗, Jobs↗, and Foundations transaction probe.