Designing Real-Time Drilling Alerts That Engineers Will Trust

A technically accurate detection algorithm is only part of an effective surveillance system. Alerts must also manage false positives, uncertainty, evidence, timing, diagnostic specificity, and operator workload.

A drilling alert has a simple job in principle:

Get someone's attention when something important is happening.

In practice, that is one of the hardest problems in real-time drilling analytics.

Consider two surveillance systems.

System A

Detects nearly every possible abnormal condition.

But it generates frequent nuisance alerts.

System B

Generates relatively few alerts.

But when one appears, engineers know that the underlying evidence is worth examining.

Which system is more useful?

The answer is not automatically System A.

A detection algorithm operates on data.

An alert operates on a human workflow.

Every alert asks someone to:

• stop what they are doing,
• evaluate new information,
• decide whether the alert is credible,
• understand its operational significance,
• and determine whether action is required.

That creates a cost even when the alert is technically correct.

If alerts repeatedly turn out to be irrelevant, premature, poorly explained, or impossible to act upon, users begin ignoring them.

Once that happens, improving the detection algorithm may no longer solve the problem.

The trust relationship has already been damaged.

This is why alert design should be treated as an engineering problem in its own right.

SPE/IADC-184743 specifically identified mental workload, data overload, user attention, interruptibility, interface design, validation, and false-alarm control as important considerations when deploying automated drilling analysis to field personnel.[1]

The underlying principle is straightforward:

A detection has value only if the information reaches the right person in a form that supports a useful decision.

An effective alerting system filters analytical detections through operational relevance, persistence, uncertainty, and human workload before interrupting the user.

Detection and Alerting Are Different Problems

Suppose an analytical model produces a continuously updated probability that a drillstring washout may be developing.

That probability might fluctuate:

0.12
0.18
0.35
0.62
0.41
0.70
0.74

Should an alert be generated the first time the value exceeds 0.50?

Maybe.

But perhaps the 0.62 value lasted only one sample before disappearing.

Perhaps the rig was transitioning between pump states.

Perhaps a sensor briefly dropped out.

Perhaps the event evidence was incomplete.

The analytical model's job is to evaluate the current evidence.

The alerting system has a different job:

Determine whether the evidence has become important enough, persistent enough, and reliable enough to interrupt a person.

That distinction creates two layers:

Detection layer

What does the data suggest?

Alert layer

Does that suggestion warrant human attention now?

Combining those into a single threshold can make the system unnecessarily fragile.

False Alarms Have a Cumulative Cost

One false alert does not usually destroy user confidence.

Repeated false alerts can.

SPE/IADC-184743 explicitly notes that false alarms greatly diminish trust in automated analysis and that detailed validation is required before exposing analytical results broadly to end users.[1]

Why does this happen?

Because users learn from the system.

If ten consecutive alerts require investigation and eight turn out to be irrelevant, the user adapts.

The implicit expectation becomes:

This is probably another false alarm.

The system has trained the user to ignore it.

That is the opposite of what surveillance is supposed to accomplish.

This creates a feedback loop:

$$ More\ False\ Alerts \rightarrow Lower\ Trust \rightarrow Less\ Attention \rightarrow Lower\ Operational\ Value $$

At some point, even a correct alert may not receive the attention it deserves.

Repeated nuisance alerts can condition users to discount the surveillance system precisely when a genuine event occurs.

Rare Events Make Alerting Statistically Difficult

There is a subtle reason false alarms can remain a problem even when a detector looks impressive in validation.

Most serious drilling failures are relatively rare.

Suppose a hypothetical event detector operates over 1,000 comparable surveillance periods.

Assume:

• 10 periods actually contain the event,
• 990 do not.

Now suppose the detector has:

• 95% sensitivity,
• 99% specificity.

That sounds excellent.

Among the 10 true events, it detects roughly:

$$ 10 \times 0.95 = 9.5 $$

But among the 990 normal periods, a 1% false-positive rate produces roughly:

$$ 990 \times 0.01 = 9.9 $$

So the alert stream contains approximately:

• 9–10 true alerts,
• 10 false alerts.

Despite apparently excellent classifier performance, only about half of the alerts may represent real events.

This is the base-rate problem.

When the event being detected is rare, even a small false-positive rate can produce a significant number of nuisance alerts.

Even strong detector performance can produce many false positives when the underlying event is rare.

That makes the operational requirement more demanding than:

Build an accurate classifier.

The practical requirement becomes:

Build a classifier whose false-positive behavior remains acceptable at the actual frequency of the event.

Sensitivity and Specificity Are Not the Only Metrics That Matter

Engineering teams often evaluate models using quantities such as:

• accuracy,
• sensitivity,
• specificity,
• precision,
• recall.

All are useful.

But an operational alert system should also be evaluated using measures closer to the user's experience.

For example:

Alerts per rig-day

How often does the system interrupt someone?

True events detected early enough to matter

An alert that appears after the crew already identified the problem provides little additional value.

False alerts per week

This directly affects trust.

Repeated alerts for the same event

One developing failure should not generate twenty separate interruptions unless there is meaningful new information.

Time from first meaningful evidence to alert

Too early can increase false alarms.

Too late can eliminate the benefit.

Actionability

Did the alert provide enough information to support an operational response?

These measures connect model performance with workflow performance.

Persistence Is Often More Useful Than a Single Threshold Crossing

Many drilling signals are noisy.

A probability or diagnostic indicator may briefly spike because of:

• sensor noise,
• a transient operation,
• incomplete data,
• communication lag,
• state transition,
• temporary hydraulic response.

If every instantaneous excursion creates an alert, the system becomes noisy.

One common solution is persistence.

Conceptually:

$$ Alert = Condition\ Elevated \quad AND \quad Condition\ Persists $$

Instead of reacting to one sample, the alert layer asks whether the evidence remains elevated long enough to be operationally meaningful.

IADC/SPE-189700 used this general principle in its field alerting workflow, averaging event evidence to suppress isolated spikes before generating washout/pump-failure alerts.[2]

The exact implementation from one field deployment should not be treated as a universal recipe.

The important concept is:

Signal persistence is evidence.

A one-second anomaly and a twenty-minute developing trend should not carry the same operational weight.

Persistence logic can prevent short-lived analytical spikes from becoming unnecessary operational interruptions.

But Excessive Filtering Can Delay the Event

Persistence introduces a tradeoff.

If the system waits too long:

• false alarms decrease,
• but warning time also decreases.

Imagine a washout beginning gradually.

An extremely conservative alert rule may wait until the evidence becomes undeniable.

At that point the rig crew may already have noticed the pressure loss.

The software has become accurate but not useful.

This means alert tuning is usually a balance between:

$$ False\ Alert\ Cost $$

and

$$ Late\ Detection\ Cost $$

The correct balance depends on the event.

For a relatively benign efficiency advisory, false alerts may be tolerated differently than for a high-consequence well-control condition.

There is no universal alert threshold appropriate for every drilling problem.

Alert timing is a tradeoff between confidence and useful intervention time; no single point is correct for every event.

Alert at the Level Supported by the Evidence

Another source of false confidence is excessive diagnostic specificity.

Suppose the data strongly suggests:

There is an abnormal hydraulic event.

But available evidence cannot reliably distinguish:

• drillstring washout,
• from mud-pump degradation.

Should the system choose one anyway?

No.

IADC/SPE-189700 provides a good example of handling this problem.[2]

Washouts and pump failures share many of the same signatures.

Rather than immediately forcing every detection into one category, the alerting workflow first recognized that one of the two related hydraulic failures was likely occurring.

The engineer then evaluated additional flow behavior to determine which explanation was better supported.

This leads to an important rule:

Diagnostic specificity should increase only when the evidence supports it.

A hierarchy might look like:

Level 1

Abnormal hydraulic behavior detected.

Level 2

Washout or pump degradation likely.

Level 3

Washout more likely based on flow behavior.

The system should not jump to Level 3 when the available data only supports Level 2.

A surveillance system should report the most specific diagnosis supported by the available evidence—not the most specific label available in the software.

"Unknown" Is a Valid Engineering Result

Good alert systems need more than:

• normal,
• abnormal.

They also need:

insufficient evidence.

Suppose a flow-out sensor fails during a developing hydraulic event.

Pressure behavior suggests a problem.

Pump strokes remain stable.

But the measurement that best separates two competing failure modes is unavailable.

The technically mature conclusion may be:

Abnormal hydraulic condition detected; insufficient evidence to distinguish failure mode.

That is not a system failure.

It is an accurate representation of the information state.

Software that always provides a confident answer can be less trustworthy than software that explicitly identifies uncertainty.

The same principle applies when:

• sensors are missing,
• contextual data is stale,
• the operation is poorly classified,
• competing explanations fit the data similarly.

Missing discriminating evidence should reduce diagnostic specificity rather than force a more confident conclusion.

Every Alert Should Answer "Why?"

Consider these two messages.

Alert A

Possible Washout Detected

Alert B

Hydraulic abnormality detected

Supporting evidence:

• pump rate stable,
• standpipe pressure progressively declining,
• measured pressure below modeled pressure,
• flow out approximately unchanged,
• pattern persisted across several minutes of stable drilling.

Which one helps the engineer more?

The second.

Not because it contains more text.

Because it contains evidence.

SPE/IADC-184743 explicitly states that an alert mechanism should provide enough information about why the alert was generated, and describes reports that include the relevant signals used in the analysis.[1]

IADC/SPE-189700 similarly generated reports containing event estimates together with pressure and flow trends leading up to the alert.[2]

This is a critical design principle.

An alert should not merely expose the model's conclusion.

It should expose enough of the model's reasoning evidence for the engineer to independently evaluate the situation.

An alert becomes easier to trust and investigate when the evidence that generated it is visible alongside the conclusion.

The Supporting Window Should Include What Happened Before the Alert

The most useful time window is rarely just the instant at which the threshold was crossed.

Engineers often need to see:

• what the signals looked like before the event,
• whether the change was gradual or sudden,
• whether another operation preceded it,
• whether the current behavior is persistent.

That argues for an alert package containing pre-event history.

For a hydraulic event, that might include the preceding:

• pressure trend,
• pump behavior,
• flow behavior,
• operational state.

For a tripping alert:

• hook-load trend,
• depth,
• modeled expectation,
• trip direction.

For a drilling-dysfunction alert:

• WOB,
• RPM,
• torque,
• ROP,
• efficiency indicator.

The correct context window depends on the physics of the event.

A rapidly developing event may need seconds or minutes.

A slowly degrading process may need hours.

The detailed Time Traces view preserves pre-event operating context and calculated loss-belief channels for engineering investigation.

Alerts Should Be Evidence-Centered, Not Dashboard-Centered

A common design mistake is sending the user to a large dashboard after an alert.

The dashboard may contain:

• 30 channels,
• multiple panels,
• gauges,
• KPIs,
• unrelated data.

The user now has to reconstruct the event manually.

The better alert experience is:

1. identify the event,
2. present the small set of evidence most relevant to it,
3. provide the larger dashboard only for deeper investigation.

This is similar to how an engineer writes a good operational note.

The first paragraph contains the material issue.

Supporting detail follows.

An alert should work the same way.

The Right Person Matters as Much as the Right Alert

Not every alert belongs with the driller.

Some issues may be better directed to:

• drilling engineer,
• wellsite supervisor,
• rig contractor,
• instrumentation personnel,
• remote operations engineer.

For example:

Sensor calibration problem

The driller may not be the person capable of correcting the instrumentation.

Potential drilling dysfunction

The driller can often change parameters immediately.

Long-term data-quality issue

This may belong to engineering or instrumentation support.

Developing equipment-health issue

The rig supervisor and maintenance personnel may need the information.

SPE/IADC-184743 used a "who, what, when, why, where and how" framework when designing real-time information delivery.[1]

That is a useful test for any alert:

Who needs this information?

What exactly do they need to know?

Why does it matter?

When should they receive it?

Where will they see it?

How should they respond?

If those questions cannot be answered, the alert is probably not fully designed.

Interruptibility Matters

A driller is not sitting at a desk waiting for notifications.

At any moment, the rig may be:

• making a connection,
• coming off bottom,
• responding to an operational issue,
• handling pipe,
• monitoring multiple systems.

An alert that appears at the wrong time can add workload instead of reducing it.

Human-factors engineering therefore distinguishes between:

information that should be immediately interruptive

and

information that can remain passive until the user is ready to inspect it.

Not every advisory deserves:

• a popup,
• an audible alarm,
• a text message.

Some conditions may be better represented as:

• a persistent indicator,
• a dashboard event marker,
• a report,
• a low-priority notification.

The interruptiveness should be proportional to:

• urgency,
• consequence,
• confidence,
• available response time.

Alert Fatigue Is Partly a Prioritization Problem

Imagine a surveillance platform simultaneously identifying:

• slight stick-slip,
• slightly reduced drilling efficiency,
• marginal hole-cleaning evidence,
• unusual torque,
• possible sensor bias,
• elevated connection time.

Should the driller receive six alerts?

Probably not.

Some conditions may be:

• related,
• low consequence,
• informational,
• appropriate for engineering review rather than immediate rig action.

A useful system should prioritize and consolidate.

For example:

Priority 1 — Immediate Operational Risk

Priority 2 — Developing Condition Requiring Attention

Priority 3 — Performance Advisory

Priority 4 — Data / Instrumentation Issue

The exact taxonomy can vary.

The principle is that alerts should reflect decision urgency, not simply algorithm activity.

Alert interruptiveness should reflect decision urgency, consequence, and confidence—not merely whether an algorithm triggered.

Repeated Alerts for the Same Event Should Add Information

Suppose a washout-type event develops over four hours.

The surveillance model remains elevated throughout that period.

Should it generate a new alert every minute?

No.

Once the user has been notified, the next alert should ideally answer:

What materially changed?

Examples:

• probability increased substantially,
• new corroborating evidence appeared,
• severity increased,
• the condition resolved and then returned.

Otherwise the system is repeating itself.

IADC/SPE-189700 explicitly incorporated controls to prevent overwhelming personnel with repeated alerts during the same developing event.[2]

Again, the specific field settings are less important than the architecture:

Alert state should have memory.

The system should know that the event has already been surfaced.

Alerts Should Distinguish Observation from Interpretation

This becomes especially important as analytics become more sophisticated.

An alert might contain several types of information.

Measured

Standpipe pressure decreased by 350 psi.

Deterministic calculation

Hydraulic model predicts pressure should have remained near the previous level under the current pump rate and geometry.

Statistical or probabilistic inference

Evidence is increasingly consistent with an abnormal hydraulic event.

Engineering interpretation

A drillstring washout is one plausible explanation.

Those are not equivalent statements.

A good alert should avoid collapsing them into:

Washout confirmed.

unless the evidence truly supports that level of certainty.

Keeping these layers separate makes the system more transparent.

Actionability Requires More Than Detection

A perfect alert that produces no useful response has limited value.

An actionable alert should help answer:

What should I check next?

This does not necessarily mean the software must prescribe an automatic action.

It may instead provide an investigation path.

For example:

Possible hydraulic abnormality

Check:

• pump configuration,
• visible leaks,
• flow-out trend,
• pressure sensor condition,
• recent pump maintenance.

Or:

Possible drilling dysfunction

Review:

• WOB,
• RPM,
• torque oscillation,
• differential pressure,
• recent parameter change.

This moves the alert from:

problem notification

toward:

decision support.

Users Need to See That Their Feedback Changes the System

Alert systems improve after deployment.

Certain conditions that looked significant in development may prove operationally irrelevant.

A specific rig configuration may create a recurring nuisance signature.

A particular hole section may legitimately tolerate behavior that would be abnormal elsewhere.

SPE/IADC-194184 describes a field deployment where user feedback led to well-specific customization, including a case where field personnel wanted mild stick-slip in a short interval treated differently. The ability to quickly modify the system increased acceptance and made users see it more as a support tool.[3] :contentReference[oaicite:3]{index=3}

This is important.

A good surveillance product should not be endlessly configurable without engineering control.

But neither should it assume that every rig, BHA, formation, and workflow behaves identically.

Trust Is Built Through Validation, Not Branding

A user does not trust an alert because the software says:

AI detected this.

That may actually create more skepticism.

Trust develops when users repeatedly observe that:

• alerts correspond to real evidence,
• nuisance alerts are corrected,
• uncertainty is represented honestly,
• the supporting data is visible,
• the system does not claim more than it knows,
• feedback produces sensible improvements.

SPE/IADC-184743 emphasizes validation before analytical results are broadly exposed to users and notes that users are more likely to trust software analysis when they can inspect evidence supporting it.[1] :contentReference[oaicite:4]{index=4}

That suggests a more durable objective than:

Make the interface look intelligent.

The objective should be:

Make the system's conclusions independently inspectable.

A Practical Alert Design

Consider a hypothetical developing drillstring hydraulic event.

At 10:00:

• SPP = 4,750 psi
• pump rate = 650 gpm
• flow out stable.

At 11:00:

• SPP = 4,680 psi.

At 12:00:

• SPP = 4,520 psi.

The hydraulic model remains near:

• 4,750 psi.

At 12:20 the analytical evidence becomes meaningfully elevated.

A weak alert might say:

WASHOUT DETECTED — 78%

A stronger alert might say:

Hydraulic Abnormality — Investigation Recommended

Observed

• Standpipe pressure progressively declined ~230 psi.
• Pump rate remained stable.
• Flow out remained approximately stable.

Expected

• Hydraulic model predicts substantially higher pressure under current operating conditions.

Interpretation

• Evidence is consistent with a reduction in circulating-system hydraulic resistance.
• Drillstring washout is one plausible cause.
• Pump degradation or sensor problems should also be evaluated.

Trend

Include synchronized SPP, pump rate, flow out, and modeled pressure for the preceding several hours.

This second alert takes slightly longer to read.

But it requires far less reconstruction by the engineer.

In DrillingMetrics, a user can open a detected event, review its engineering context, and inspect the synchronized measurements and calculated loss belief behind it.

A Practical Alert Checklist

Before deploying a new drilling alert, ask:

Detection

• What physical or operational condition is being detected?
• What independent evidence supports it?
• What competing explanations exist?

Reliability

• What is the false-alert rate on representative wells?
• What happens when sensors are missing?
• Can the system report uncertainty?

Persistence

• Does the event need to persist?
• Could short operational transitions trigger the condition?
• How much warning time is lost through filtering?

Specificity

• Is the alert claiming more diagnostic certainty than the evidence supports?
• Would a broader event category be more defensible?

Evidence

• Can the user immediately see why the alert occurred?
• Are measured and expected values distinguished?
• Is sufficient pre-event history provided?

Human workflow

• Who should receive it?
• Does that person have the ability to act?
• How interruptive should it be?
• Should the condition be a popup, passive indicator, report, or message?

Follow-up

• What should the user investigate?
• What constitutes event resolution?
• When should the system alert again?

If those questions are unanswered, the detection model may be ready while the alert product is not.

The Best Alert Is Not the One That Fires First

Real-time surveillance naturally creates pressure to detect events earlier.

Earlier is valuable.

But earlier is not automatically better.

The useful objective is closer to:

Alert at the earliest point where the evidence is strong enough to justify the interruption and there is still enough time for the user to act.

That balances:

• detection lead time,
• false alarms,
• uncertainty,
• operational consequence,
• human attention.

It is fundamentally a decision problem.

Not simply a classification problem.

From Algorithm Output to Operational Decision Support

A drilling surveillance system typically begins with an analytical question:

Can we detect this event from the data?

A mature implementation asks a broader sequence:

Can we detect it reliably?

Can we detect it early enough to matter?

Can we distinguish it from competing explanations?

Can we explain why the detection occurred?

Can we avoid repeatedly interrupting the user?

Can the recipient actually do something useful with the information?

That progression is what turns analytics into decision support.

A useful alert is the output of a closed-loop engineering process, not a one-way alarm generator.

The engineering model may determine what the data means.

The alerting layer determines when that meaning deserves human attention.

And the human-factors layer determines whether the information will actually influence the operation.

The most sophisticated detector in the world has little value if the user has learned to dismiss its alerts.

The goal is therefore not more alarms.

It is fewer, better-supported, better-timed engineering interruptions that consistently deserve attention.

---

References

1. Behounek, M., Thetford, T., Yang, L., Hofer, E., White, M., Ashok, P., Ambrus, A., and Ramos, D. Human Factors Engineering in the Design and Deployment of a Novel Data Aggregation and Distribution System for Drilling Operations. SPE/IADC-184743-MS, SPE/IADC Drilling Conference and Exhibition, The Hague, Netherlands, 2017.

2. Ambrus, A., Ashok, P., Ramos, D., Chintapalli, A., Susich, A., Thetford, T., Nelson, B., Shahri, M., McNab, J., and Behounek, M. Self-Learning Probabilistic Detection and Alerting of Drillstring Washout and Pump Failure Incidents During Drilling Operations. IADC/SPE-189700-MS, IADC/SPE Drilling Conference and Exhibition, Fort Worth, Texas, 2018.

3. Behounek, M., Millican, B., Nelson, B., Wicks, M., Rintala, E., White, M., Thetford, T., Ashok, P., and Ramos, D. Change Management Challenges Deploying a Rig-Based Drilling Advisory System. SPE/IADC-194184-MS, SPE/IADC International Drilling Conference and Exhibition, The Hague, Netherlands, 2019.