A production report tells you what a well made. A downtime and deferment report tells you what it should have made and did not, and why. It is the artifact operators use to quantify lost production - the barrels and cubic feet a well would have produced if it had run - and to attribute those losses to specific causes so they can be reduced. This guide explains what goes on the report, how deferment is calculated against a baseline, how losses are categorized with reason codes, and how a SCADA system can detect a well going down and log the event automatically so the report writes itself.
Downtime & Deferment Report in one line: A downtime and deferment report quantifies and categorizes lost production: it records when each well was down, assigns a reason code for the cause, and estimates the deferred volume - the difference between what the well would have produced and what it actually produced. The report rolls those losses up by cause and by asset so operators can see where uptime is being lost, and SCADA can detect and time-stamp the outage automatically to feed it.
Deferment is the gap between potential and actual production. To compute it you need a baseline - a rate the well was expected to produce, usually drawn from its recent test or its established decline curve - and a record of how long it was off that rate. Multiply the shortfall in rate by the duration of the outage and you have the deferred volume, expressed in barrels of oil or thousands of cubic feet of gas. A well that normally makes a hundred barrels a day and is down for six hours has deferred roughly twenty-five barrels; the report captures that number so the loss is visible rather than silently absorbed into a lower daily figure.
Deferment is not the same as downtime, though the two are reported together. Downtime is the time a well was not producing at all; deferment also captures underperformance - a well that ran but at a reduced rate because of a partial choke, a failing pump, or a backpressure problem still deferred volume even though it never fully stopped. A good report separates full outages from partial losses, because a well quietly producing at seventy percent for a month can defer more than one that tripped clean for a day and was quickly restored. The point of measuring deferment at all is to turn invisible, chronic losses into a number someone is accountable for.
A raw list of deferred barrels is not actionable until each loss carries a cause. That is the job of reason codes: a standardized set of categories - artificial lift failure, surface facility constraint, planned maintenance, pipeline or takeaway restriction, weather, third-party outage, waiting on service - assigned to every downtime event. Coding every event consistently is what makes the report useful, because it lets losses be summed not just per well but per cause. When the report rolls up by reason code across a field, it answers the question that actually drives decisions: where is our uptime going, and is it the pumps, the compression, the takeaway, or something we planned?
The same events roll up along the asset dimension too - by well, by pad, by battery, by field, by operating area - so a supervisor can rank locations by deferred volume and focus attention where it pays. The combination is powerful: a rollup showing that half a field's deferment traces to one reason code at three pads tells an operations team exactly where to send resources. Consistency is everything here. If two pumpers code the same failure differently, the rollups blur and the report loses its ability to point at a systemic problem. Many operations therefore constrain reason codes to a fixed picklist rather than free text.
The weakest link in a manual deferment report is knowing when the well actually went down. If the only signal is a pumper's next visit, the outage start time is a guess and the deferred volume is guessed with it. A SCADA system removes that guesswork because it is already watching the well continuously. When a run status contact opens, a tubing pressure collapses, a flow rate drops to zero, or a pump-off controller trips, the platform sees it in real time and time-stamps the moment the well left production. That exact start time, paired with the moment production resumes, gives an accurate outage duration - and accurate duration is what makes the deferred volume trustworthy.
A cloud SCADA platform such as Merobix can auto-log each of these events with its start, end, and duration, then apply the well's expected rate to compute deferment without anyone stopwatching the field. Because the platform also alarms on the outage as it happens, the same event that populates the end-of-period report can page an operator the instant the well trips, shortening the outage itself. The report then becomes a rollup of machine-detected events that the pumper only needs to code with a reason, rather than a reconstruction assembled from memory and gauge sheets. That is the difference between a deferment report that estimates the past and one that measures it - and, because the detection is real-time, one that helps prevent the very losses it counts.
Downtime is the amount of time a well was not producing. Deferment is the volume of production lost during that time - and it also includes underperformance, where a well ran but at a reduced rate. A well can defer production without ever fully stopping, so a report that tracks only downtime misses the chronic, partial losses that deferment captures.
You take the well's expected rate - usually from its most recent test or its decline curve - and multiply the shortfall from that rate by the duration of the outage or the underperformance. A well that should make a hundred barrels a day and is down for six hours has deferred roughly twenty-five barrels. Accurate outage timing is what makes the number trustworthy, which is why SCADA-detected start and end times matter.
Because the value of the report comes from rolling losses up by cause, and that only works if the same failure is always coded the same way. If two operators label an identical pump failure differently, the rollups blur and the report can no longer point at a systemic problem. Most operations use a fixed picklist of reason codes rather than free text to keep the categorization consistent.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.