Status: Delivered. Described from our own delivery records. Client identity, brand and commercial terms are withheld. Figures, where given, cover the period stated and nothing beyond it.
Context
A revenue-cycle operation exchanging hundreds of inbound and outbound files each day with client facilities over secure file transfer.
Those files carry the data the rest of the operation runs on.
The problem
- Files were sometimes missing or delayed, and nothing was watching for that.
- The absence surfaced later as a downstream data problem, and later still as a client escalation — by which point it had already cost something.
- There was no record of what had arrived and what had not, so diagnosis started from scratch each time.
- The volume made manual checking impractical.
What we built
A file watcher
Monitoring the transfer server, evaluating what arrived against what was expected on each schedule.
Missing-file detection with proactive alerting
So an absence is an event rather than an inference drawn days later.
A multi-dashboard web portal
Showing arrival status, delays and patterns, with the history to see whether a source has become unreliable rather than just late once.
How we delivered it
- 1
Establish the expectation
What should arrive, from whom, on what cadence. This had never been written down, and writing it down was half the value.
- 2
Build the watcher
Against that expectation, starting in observe-only mode.
- 3
Tune the thresholds on real traffic
Because an alerting system that cries wolf gets muted within a fortnight.
- 4
Add the dashboard
For status and history.
- 5
Hand over the runbook
What to do when each type of alert fires.
How it was phased
Indicative phasing for work of this shape. Actual duration varies with data quality, access and decision speed.
What the client keeps
- The watcher and dashboard source in their own repository
- The expectation register
- Alert thresholds and routing configuration
- The response runbook