v1.3.0 — the monitor stops exiting zero on a failed ship

The fix

telemetry:monitor discarded flush()'s report and returned success from --once regardless. Read from cron the exit code is the whole report, so a host that sampled fine and then could not ship looked identical to a healthy one.

This is the same blind spot telemetry:flush had, one command over. It survived v1.2.0 because nothing pointed at it.

• --once reports the exporter, the summary and each problem, logs at error, and exits non-zero.
• The daemon reports to the log instead, and only when the failure changes — a collector down for an hour must not write 3,600 identical lines — and says so once when batches start landing again.
• flush() is wrapped in FailSafe like the samplers on either side of it, so a throwing exporter no longer takes the loop down. It reports as a failure and the next tick tries again.

Why this is a minor and not a patch

telemetry:monitor --once now exits non-zero where it always exited zero. Nothing in the API changed and no signature moved, but anything wrapping that command in cron, a health check or CI will start failing where it previously passed — which is the point of the change, and exactly the kind of thing that should not arrive in a patch.

If a run is failing after this upgrade, it was failing before too; you are seeing it for the first time. The output names the exporter and carries the backend's own reason.

Upgrading

composer update cboxdk/laravel-telemetry

No configuration changes. If you deliberately want a sampling run to be advisory, handle the exit code at the call site rather than in the command.