A production engineer responsible for hundreds or thousands of wells cannot open a chart for each one every morning and still get anything done. Exception-based surveillance is the practice that makes that workload tractable: instead of reviewing every well, the engineer is handed a short, ranked list of just the wells that broke a rule overnight and works down it in priority order. This guide explains how exception-based surveillance defines those rules, builds and ranks the exception list from field data, and turns a daily flood of readings into a focused set of decisions. It is a production-engineering workflow, distinct from the telemetry-level idea of reporting values only when they change.
Exception-Based Surveillance in one line: Exception-based surveillance is a production-engineering practice in which engineers monitor a large population of wells by reviewing only the ones that violate predefined surveillance rules - such as a rate drop beyond a threshold, a pressure outside limits, or unexpected downtime - rather than examining every well individually. A system compares each well's latest data against its rules and produces a ranked exception list, so attention goes first to the wells that most need it. The goal is to manage by exception at scale, catching problems early without drowning engineers in normal readings.
The problem exception-based surveillance solves is one of arithmetic. When a team is accountable for a few thousand producing wells, there is no realistic way to inspect each one on a daily cadence, and most of that inspection would be wasted because the overwhelming majority of wells are behaving exactly as expected on any given day. Reviewing everything treats a well that is quietly on plan the same as a well whose rate just collapsed, and that flat treatment is precisely what buries the important signal. Exception-based surveillance inverts the default: the assumption is that a well is fine unless it trips a rule, and only the wells that trip get looked at.
That shift changes what an engineer's morning looks like. Rather than paging through dashboards hoping to notice something, the engineer opens a list of wells that already crossed a line - a producer whose oil rate fell more than its allowed decline, an injector outside its pressure window, a well that reported zero flow when it should have been running. The list is the work queue. Everything not on it has been implicitly cleared, which frees the engineer to spend judgment on diagnosis and intervention instead of on scanning. The discipline is sometimes abbreviated EBS or called surveillance by exception, but the idea is the same: govern attention with rules so it lands where it is needed.
It is worth being clear about what exception-based surveillance is not. It is not a telemetry technique about when a device transmits a reading, and it is not about deadbands that suppress small changes on the wire. Those concern how data gets from the field to the system efficiently. Exception-based surveillance operates a layer up, on data that has already arrived, and asks a different question: given everything we now know about this well, does it warrant a human decision today? It is a workflow for engineers, not a compression setting for radios.
The list starts with rules, and the rules encode what abnormal means for each kind of well. Common ones test rate against an expected decline curve or a recent baseline, so a producer flags when its output drops faster than the trend predicts. Others watch operating pressures against high and low limits, test for downtime by catching wells that stopped when they were scheduled to run, or look for a parameter drifting toward a constraint. Good rules are specific enough to fire on real problems and forgiving enough to ignore the normal scatter of a producing well, because a rule that cries wolf trains engineers to ignore the whole list.
Raising an exception is only half the design; the other half is ranking, because on a bad day the list can still be long. Exceptions are usually ordered so the most consequential wells rise to the top - by lost production potential, by severity of the breach, by economic value, or by how many rules a single well tripped at once. A well losing a large volume outranks one that slipped just past its threshold, and a well breaching a safety-related pressure limit outranks a routine rate dip. The point of ranking is to guarantee that even when the engineer only gets through part of the list, the part they get through is the part that mattered most.
The output is often circulated as a production surveillance report or a live exception queue that the team works down and clears, annotating each item with what was found and what action was taken. That closure matters: an exception that is acknowledged, diagnosed, and resolved leaves a record, and the pattern of exceptions over time tells its own story about which wells, fields, or failure modes keep recurring. Well-run programs also tune the rules from that history, tightening ones that miss real events and relaxing ones that fire on noise, so the list stays trustworthy rather than degrading into background clutter.
Exception-based surveillance is only as good as the data it evaluates, and in modern operations that data comes from SCADA. Rates, tubing and casing pressures, run status, and injection parameters are gathered from the field continuously, and it is that steady stream of current values - checked against each well's rules - that lets exceptions be generated automatically each cycle rather than assembled by hand. Without reliable field data arriving on a dependable cadence, the surveillance list is built on stale or missing numbers, and a well that is actually in trouble can sit quietly off the list because nothing recent was there to test.
A cloud SCADA platform such as Merobix suits this workflow because it centralizes live and historical field data across every well and site in one place, which is exactly what rule evaluation needs. Comparing today's rate to an expected decline requires history; catching unexpected downtime requires knowing the well's schedule and its current run status; ranking by lost production requires a sense of what the well should be making. When all of that lives in one accessible record, the exception list can be computed against complete context, and an engineer can click straight from a flagged well into its trends to diagnose it without hunting across separate systems.
The two disciplines are complementary rather than competing. Real-time SCADA alarms handle the immediate, safety-relevant trips that demand action within minutes, while exception-based surveillance handles the slower, economic and reliability questions that are best answered once a day against fuller context - a gradual decline, a creeping pressure, a pattern of short shutdowns. Feeding surveillance rules from the same field data that drives the live system means both layers see the same truth, and the engineer's ranked list becomes a trustworthy daily summary of where the well population actually needs attention.
They operate at different layers and solve different problems. Report by exception is a telemetry technique about when a field device transmits a value - typically only when it changes past a deadband - to save bandwidth and power. Exception-based surveillance is a production-engineering workflow that runs on data already collected, applying rules to decide which wells need an engineer's attention today. One is about efficient data transport; the other is about focusing human review across a large well set.
Typical rules test production rate against an expected decline or recent baseline, check operating pressures against high and low limits, detect unexpected downtime by catching wells that stopped when scheduled to run, and watch parameters drifting toward a constraint. Effective rules are specific enough to fire on genuine problems yet tolerant of the normal scatter of a producing well, since a rule that generates false alarms trains engineers to distrust the entire list.
Because even a well-tuned list can be long on a difficult day, and an engineer may not clear all of it. Ranking - by lost production, breach severity, economic value, or how many rules a well tripped - ensures that whatever portion of the list gets worked is the portion that matters most. It guarantees the highest-consequence wells are addressed first rather than lost among minor threshold slips.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.