What Is Runtime & Downtime Tracking?

Back to Blog

How Runtime and Downtime Are Measured

At its simplest, a SCADA system watches a run status - a motor contactor, a pump discharge pressure, a flow above a threshold - and accumulates the time in each state. Runtime is the total time running; downtime is the total time stopped. From these, availability is calculated as runtime divided by the total scheduled time, usually expressed as a percentage. The same run counters also feed maintenance, since many service intervals are based on operating hours rather than calendar time.

The real value appears when downtime is categorized. Attaching reason codes - waiting on power, mechanical failure, planned maintenance, no feed, operator hold - converts raw downtime into an analysis of why production is lost. That is what lets a team rank causes and attack the biggest one, rather than knowing only that a site was down.

Why It Matters in Oil & Gas Operations

Across a large field, small differences in well or compressor availability compound into significant production and revenue. Tracking runtime per well surfaces the units that cycle or shut in most often; tracking downtime by reason surfaces whether the losses are electrical, mechanical, or operational. This directly informs where to send crews and where to invest in reliability.

Because SCADA already reads run status and flow from every site, runtime and downtime tracking is largely a matter of accumulating and reporting data the system is collecting anyway. A cloud SCADA platform that historizes this state can report availability and downtime by site and by reason across an entire operation, viewable in a browser, so a supervisor can compare uptime across dozens of remote wells without pulling logs from each one.

Choosing a Trustworthy Run Signal

Everything downstream - availability figures, reason-code analysis, maintenance triggers - inherits the quality of the run signal, so choose it deliberately. An auxiliary contact on the motor starter proves the starter closed, not that the pump moved fluid. Motor current proves the shaft is loaded. Discharge pressure or flow above a threshold proves useful work. Each step up that ladder is a more honest runtime signal, and the honest ones are the ones worth accumulating.

Wherever possible, validate one signal against another: run status that says running while flow says zero is either a broken belt, a gas-locked pump, or a lying input, and every one of those is worth an alarm of its own. Debounce is the other essential - a threshold-based run signal will flutter at the boundary, and without a short qualification time the system records dozens of phantom starts and stops that poison both the counts and the cycle statistics.

On beam pump wells the run signal has one more subtlety: pump-off controllers stop and start the unit all day by design, so raw start counts mean something different than they do on a compressor. Runtime there is best read alongside the controller's own cycle data - the baseline exercise covered in how to baseline a pump-off controller runtime - so normal cycling is not mistaken for trouble.

Building a Reason-Code Set People Will Use

Reason codes fail in two directions: too few and the analysis says nothing, too many and the field stops filling them in. A workable set has a single level of a handful of mutually exclusive buckets, with an explicit other category that gets reviewed - a growing other bucket is the signal to add a code, not a failure of discipline.

Bucket	Example causes	Usually assigned by
Power	Utility outage, generator down, breaker trip	Automatic, from site power status
Mechanical	Pump, engine, or compressor failure	Operator or mechanic
Planned	Scheduled maintenance, workover, inspection	Operator, from the schedule
Process	No feed, high line pressure, tank full	Automatic, from process context
Comms unknown	Telemetry outage masking true state	Automatic, flagged for review

Automate what can be automated. If the ESD tripped, the system knows; if site power dropped, the system knows; if telemetry was out, the honest code is unknown, not a guess. Reserving human entry for the cases only a human can classify keeps the burden small enough that people keep doing it.

Feeding Maintenance and Reliability Metrics

Accumulated run hours are the natural trigger for service on rotating equipment, since wear follows operation rather than the calendar. Feeding SCADA runtime into the maintenance system replaces guessed intervals with measured ones - the pattern described in runtime hours maintenance trigger. The same event log that produces downtime totals also yields failure counts, and with them reliability arithmetic such as MTBF per unit.

The discipline that makes these numbers meaningful is separating planned from unplanned downtime at the source. A unit down for scheduled service is not failing, and mixing the two makes reliable equipment look bad and failing equipment look average. That separation is exactly what the reason codes buy, which closes the loop on why they are worth the field's time.

A Worked Availability Calculation

Run the arithmetic on a symbolic month. A well is scheduled to produce all 720 hours. The tracker records 684 hours running and 36 hours down, so availability is 684 divided by 720, or 95 percent. The 36 hours split by reason code: 20 waiting on site power, 12 on a pump failure, and 4 planned for a service call.

The split is the actionable part. Availability alone says the well ran most of the time; the codes say that fixing power reliability would recover more production than any mechanical improvement. Multiply that reasoning across a field and the downtime report becomes the priority list for the operations budget, which is the entire point of tracking the numbers in the first place. The same worked pattern scales down to a single compressor and up to a district, as long as the run signal and the codes are consistent.

Frequently Asked Questions