Trust / Monitoring
The failure that matters is the one that goes quiet
Alerting on errors is ordinary. Alerting on the absence of an expected event — a backup that stopped running, a verification that stopped verifying — is the part most platforms miss.
A job that fails loudly gets fixed the same day. A job that silently stops is discovered months later, at the moment you needed it.
Ask what we watchWhat breaks without anybody noticing?
Scheduled work. Nightly backups, weekly restore verification, delinquency sweeps, model staleness — all things that produce no error when they simply stop happening. Dead-man alarms invert the logic: the alarm fires when the expected event does not arrive.
Presence, not just errors
What is watched, and how the alarm is shaped
- 01
Dead-man alarms on backups
The alarm expects a completion signal on schedule. No signal is itself the alert, so a backup that stopped running two weeks ago is a page, not a discovery during an incident.
- 02
Dead-man alarms on verification
The weekly restore check is watched the same way. A verification that quietly stopped means the backups have been unproven since, which is materially worse than a failed check.
- 03
Model staleness alerts
When an active predictive model ages past its threshold, operators are alerted. The model does not retrain and re-promote itself — a model that changes its own behavior is one nobody can explain later.
- 04
Sweep and batch outcomes
Collection sweeps and batch jobs run under named service principals, and their outcomes are recorded. A failed batch can be re-run by an IT Billing Admin; a successful one cannot be re-run at all.
- 05
Redaction before shipping
Logs are redacted at write time, before they are shipped to monitoring tools. Monitoring is where personal data usually leaks out of an otherwise careful system.
What an operator sees
Operator visibility, without reading your claims
Waypoint’s own console administers the platform, not the claims on it. Where an operator screen must reference a claim, the identifier is stripped — so we can run the service without our staff browsing your customers’ records.
Backup completion
Present on schedule, or the an alert is raised
Restore verification
Ran, and produced a timed recovery figure
Model age
Active models within their staleness threshold
Batch outcomes
Per service principal, with re-run available only for failures
AI spend
Per organization, with claim identifiers stripped
Log contents
Redacted at write time — no personal data in the journal
Claim content
Not readable from the operator console at all
What monitoring is not
Good observability shortens the time between something breaking and somebody knowing. It does not prevent the break, and it is not an uptime commitment.
Not prevention
An alarm is a fast discovery, not a guarantee. Prevention lives in the release gate and the reversible migrations, which are a different mechanism.
Not a published SLA
We monitor closely and we have not operated long enough to publish an availability figure we would defend. Ask what we actually run rather than what we would like to claim.
On-call is small
We are an early-stage team. Our response depth is not that of a vendor with a follow-the-sun operations center, and pretending otherwise would be the easiest lie on this page.