Insights · Data

Silent failure is the only kind of failure reporting has

By the YMME team·7 min read·September 2026

A property system stops exporting on a Tuesday evening. Nobody changed anything; a certificate expired, or a password was rotated, or a vendor moved a folder. On Wednesday morning the group summary goes out on time, the cards are green, and the property’s numbers are Tuesday’s. Nothing crashed and nobody was alerted. The figure stays wrong for over a week, until a controller notices that the weekend never happened.

Quick answer. Reporting fails silently, by disagreeing with reality while looking healthy. The defence is a source monitor that knows, for every feed, when it should have arrived and when it did; that records each incident; that quarantines suspicious data rather than dropping it; and that raises one alert per problem. Fire an alert hourly and the channel is muted by Thursday.

Why nothing alerts

Software monitoring is built around crashes. A process dies, a port stops answering, a disk fills; something is measurably broken and an alarm fires. Reporting rarely fails that way. The loader runs, finds no new file, logs “nothing to do” and exits cleanly. The database is up. The screens render. Every technical check passes, and the number is stale.

Only 15% of hotels say they are confident in the accuracy of their own data, according to the 2026 Hotel Operations Index. Some of that is definitions. A good part of it is figures that were right when they were loaded and have since stopped being current, with nothing in the system to say so.

Freshness only means something against a promise

A timestamp on a figure is necessary and not sufficient. The reader has to know what the timestamp should be. A night-audit feed that arrived just after six is fine on a property that closes at six and alarming on one that closes at four. A payment gateway that settles two days later is fresh at two days old; a till export is late after four hours.

So the monitor keeps a registry. For every source on every property it holds how often the feed is expected, by when, and when it last arrived and passed its checks. It holds who is told when the promise is broken, which should be the person who can fix the feed rather than the whole group. And it holds the history: each incident opened, updated and closed, so the gaps in the data have a record of their own. Freshness is the distance between the promise and the fact. When that distance passes the threshold, the source is late, even though nothing is technically broken.

One alert per problem

The first monitor anybody builds checks every hour and sends a message every hour the problem persists. By the third day the channel is full of identical warnings and the person responsible has muted it. On the fourth day a second source fails, and nobody sees it.

The rule is one alert per problem. It opens when the source first goes late, is updated if the situation changes, and closes when the source recovers, with the incident kept in the registry. The monitor is itself a distribution, independent of the others, with its own recipients.

Fire it hourly and the channel is muted by Thursday.

What the screen should do meanwhile

While a source is late, the figure it feeds has to look different. The last good number stays visible, because it is still the best information available, but it carries the time it was true, and the screen’s status shows the property as partial with the reason. The group total is not quietly reduced, because a delayed feed is not a fall in revenue.

When data arrives that looks wrong, say a night’s transactions posted twice after a restart, the duplicates are caught by transaction id and held to one side rather than loaded or discarded. The affected figure is flagged as partial. Nothing is adjusted to make the total balance.

The failure you cannot see is the expensive one

A crashed report costs a morning. A stale report that looks current costs whatever decision was taken on it: a rate held when it should have moved, a staffing level set to last week’s occupancy, a supplier paid twice because the first payment never reached the ledger export. None of those appear on an invoice for reporting. All of them are the cost of reporting that had no way to say it was wrong.

The test of a reporting layer is not whether its screens are beautiful. It is what happens on the Tuesday evening when a source goes quiet, and whether anyone knows by Wednesday morning.

How this is built in Score. YMME Score keeps a registry of every source with its expected cadence, checks freshness against it, records each incident and raises one alert per problem to the people who can fix it. Suspicious data is quarantined and the affected figure marked partial; the last good number stays on screen with the time it was true. Source connections are read-only, so the monitor can never damage the systems it watches.