Features

Downtime analytics

This page is about the mechanism: where the clock starts, where it stops, who decides the interval was real, and what happens to the arithmetic when nobody has told the system what an hour of that device is worth. If you are trying to establish what downtime is costing the organisation, the Solutions page is the better starting point.

  • Biomedical engineering
  • Executive and finance
  • Hospital operations
Looking for the other side?Downtime managementIf your question is "what is downtime actually costing us, and which devices are worst", start there instead. It is written for the problem rather than the mechanism.

What is downtime analytics?

Definition

Downtime analytics

Downtime analytics is the measurement of how long a device was unavailable, the attribution of that interval to a cause, and its conversion into a financial figure using a rate the organisation configured rather than one the software assumed.

Three separate claims are hiding in that sentence, and they fail independently. The interval can be right while the attribution is wrong. Both can be right while the money is fiction. Presented with equal confidence, the three read as a single claim, which is how a number that nobody can defend ends up in a board pack.

Rydya keeps them separate on purpose. The interval is measured. The attribution is recorded with who decided it. The money is a conversion that either has a configured rate behind it or does not happen at all.

How an hour becomes a figure

Interval, then rate, then impact, with the rate coming from your configuration at every step.

A flow showing a downtime interval measured from start to end, then combined with a configured hourly rate to produce an estimated impact record. Where no rate is configured, the flow stops at the interval and the impact is shown as not configured rather than as zero.Asset valueYou configure itDuration downMeasured, not guessedEstimated costIn your currency
A downtime interval is measured first and priced second, never the other way round.

Where the clock starts and stops

It starts when the device stopped being available, not when someone got round to logging it, and it stops at an authorised return to service.

  1. 1

    The interval opens

    A fault report, a quarantine decision or a planned intervention opens a downtime event against the asset. The start is the time the device became unavailable, which is frequently earlier than the time anyone reported it. That gap is itself worth seeing.

  2. 2

    The interval accrues while the work happens

    It is not paused because the job is waiting on a part or a vendor. Waiting is downtime. A system that only counts the hours a technician had a spanner in their hand is measuring effort, not availability.

  3. 3

    The interval closes at return to service

    Not at "the engineer says it is fixed". Return to service is a gate: the required tests, then an authorised clearance. The device is unavailable until it is cleared, so that is when the clock stops.

  4. 4

    The worker catches what people forget

    Intervals left open, intervals still running after a return to service, intervals that have gone stale. These are flagged rather than silently corrected, because a wrong interval nobody knows about is worse than an open one somebody has to close.

What the measurement will not do

The refusals are the reason the outputs are usable in a business case at all.

It will not invent a rate

If nobody has configured what an hour of that device is worth, the impact reads "downtime cost not configured". Not zero, which would quietly drag every average down, and not an industry benchmark, which would be a number about somebody else's hospital.

It will not merge estimated and confirmed impact

An estimate built from a revenue figure and a confirmed cost from a real invoice are different records with different weight. Merging them produces a total that is defensible in neither direction.

It will not overwrite the original amount

Money is stored with its original amount and currency, immutable. A conversion lives separately, carrying its rate id, source and timestamp. So a figure quoted six months ago can still be reproduced exactly.

It will not let a correction edit history

Corrections to a closed financial record are audited amendments, not edits in place. The trail shows what was believed then and what is believed now, which is what makes it survive an audit.

Estimated against confirmed impact

Both are useful. Confusing them is what destroys the credibility of the whole number.

The two impact types and what each is good for
AspectEstimated impactConfirmed impact
Comes fromA revenue figure configured against the assetA real cost that was actually incurred
AvailableAs soon as the interval is measuredOnce the invoice or cost lands
Good forRanking devices, triage, a business caseReporting what was spent
Stored asIts own record, sourced and labelledIts own record, never merged into the estimate
If unconfiguredNot shown, and not counted as zeroSimply absent until it exists

The two impact types and what each is good for

Attribution, and why it needs a person

Because cause is a judgement, and a system that guesses at it produces a report that reads as authoritative and is not.

It is tempting to derive cause automatically from the fault category. It is also how you end up with forty per cent of your estate attributed to "other" and a reliability picture that nobody in the department believes. Cause in this domain is often genuinely contested: a pump that failed because it was overdue is a maintenance failure, unless it was overdue because the ward would not release it, in which case it is something else entirely.

Rydya records the attribution along with who made it and when, in the same transaction as the change, append-only. That does not make the attribution correct. It makes it accountable, which is the most software can honestly offer here, and it means a disputed figure can be traced to a decision rather than to an algorithm nobody can interrogate.

Questions

Does the clock stop when the engineer finishes the repair?

No, it stops at an authorised return to service. The device is unavailable to the ward until it has passed the required tests and been cleared by someone entitled to clear it, so that is when it becomes available again. Stopping the clock at "the engineer says it is fixed" would measure repair effort while claiming to measure availability.

What happens if we have not configured a cost for a device?

The interval is still measured, and the impact reads "downtime cost not configured" rather than zero. Zero would be a lie that averages down, and an industry benchmark would be a fact about someone else's hospital. The measurement stands on its own until you supply the rate.

Is waiting for a part counted as downtime?

Yes. The device is unavailable whether a technician is working on it or a courier is. A tool that only counts hands-on hours is reporting effort and calling it availability, and it will make a part-supply problem invisible in exactly the report that should expose it.

Can we correct an interval that was recorded wrongly?

Yes, as an audited amendment rather than an edit in place. The trail keeps what was recorded and what it was corrected to, with who did it. Closed financial records are never edited silently, because a figure that can change without trace is a figure that cannot be defended.

See it on your equipment

Live in an afternoon, useful the same week. A person replies, usually within one working day.

Contact us