đź“Ś Key Takeaways
Explain a pump runtime change by checking its signal, reporting times, and missing data before assigning a cause.
Runtime Does Not Explain Cause: A runtime record shows how long a pump ran, but the number alone cannot explain a change.
Check What Sensors Measure: Running and stopped signals support runtime records, while measured amperage shows how much electrical current a motor draws.
Reporting Times Limit Detail: Reports show readings at specific times, so matching values cannot prove steady behavior between reports.
Missing Reports Leave Questions: Missing reports and connection warnings leave gaps; they cannot prove normal operation or a pump fault.
Keep Open Questions Visible: A clear maintenance handoff states what changed, what supports it, and what still needs a field check.
State what changed; check what caused it.
Pump station supervisors and maintenance managers will find a clear way to explain runtime changes in the evidence framework below.
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
From an Unexplained Reading to a Statement You Can Defend
The runtime number moved overnight.
Early in the morning at the operations desk, a buzzing phone interrupts review of an unexplained runtime change. The reading is visible, but the record does not yet show whether enough signal and time context exists to explain it. It might be a simple line on a screen showing “Pump 2: 14.2 Hours,” stripped of any clues about why it jumped from yesterday's baseline.
You already know what a runtime is. What you lack in that moment is context, and someone will ask for an explanation before the morning is out. Is this the pump, or is this the report? The danger isn’t the number itself. It is acting on an interpretation the record cannot support, or overlooking a gap in the monitoring path that changes what the number means.
The tempting response is to let the visible reading explain itself. That approach breaks down whenever the record lacks the signal or time context behind the number, because missing context cannot supply a cause. The Pump Monitoring Evidence Framework is a conceptual structure for exactly this situation. It gives you a disciplined way to say what a station record shows, what limits its meaning, and what still needs confirmation, so you can bring one defensible statement to a maintenance review instead of a guess.
The legend below is where that statement starts.
What a Pump Runtime Record Can Establish
A pump runtime record can show recorded operating duration within the applicable reporting context, but it cannot independently explain the cause of a change. The Pump Monitoring Evidence Framework keeps those two claims apart: the record establishes that a duration changed, while any explanation needs evidence of its own.
The difference is easy to state and easy to lose in a busy review. “Pump 2 ran longer this week” is an observation drawn from the record. “Pump 2 ran longer because of wear” is a causal claim, and the record alone cannot carry it. Inflow, control settings, the reporting interval, and the condition of the monitoring connection can all sit behind the same number, and none of them is visible in the runtime figure itself.
An instrument panel is a useful way to picture this. A gauge shows where a needle sits. It does not tell you which sensor feeds it, how often it updates, or whether its connection dropped overnight. The framework works like the legend printed beside that panel, labeling each reading with what it measures and how far it can be trusted.
Four terms keep these claims from blurring:
Observation is what the record directly shows.
Evidence is the signal and reporting context behind that observation.
Inference is a possible explanation still waiting to be evaluated.
Confirmation is the technical, operational, or field evidence that supports that explanation.
The aim is not to eliminate uncertainty but to define it accurately.
That is why the framework organizes a maintenance discussion rather than diagnosing equipment. It narrows the claim. People at the station test it.
The Runtime Evidence Legend
The Runtime Evidence Legend is a six-question check that turns a changed reading into a bounded statement. Work through it in order before anyone proposes a cause.
Evidence question | What to record | Interpretation boundary |
|---|---|---|
What changed? | State the runtime observation without adding a cause. | A changed duration is not an explanation. |
What signal is available? | Identify whether the record reflects current presence, measured magnitude, runtime, level, flow, or another documented input. Confirm what is installed at this station. | Different inputs provide different evidence. |
What is the reporting interval? | Identify the applicable service plan and recorded interval. Intervals may vary by device, connected sensors, and wireless-service package. | A reporting interval is not continuous analog sampling. |
Is the record continuous enough? | Note missing reports, weak-signal or reporting-failure warnings, and uncertain timestamps. | Missing context cannot be treated as normal operation. |
What can the record establish? | State the narrow conclusion the available evidence supports. | Avoid mechanical or causal claims the source cannot support. |
What remains unanswered? | Name the question requiring appropriate technical or field confirmation. | The framework organizes the question; it does not resolve unsupported causes. |
The first row strips any cause out of the observation. Rows two through four describe the evidence itself: what kind of signal it is, how often it reaches the record, and whether it arrived intact. Row five is the sentence you can defend in a meeting. Row six keeps the unresolved question visible so it does not quietly harden into an assumption, and it marks the point where monitoring evidence stops and confirmation begins.
A common pitfall is jumping from row one directly to row five. The reading looks clear, so a conclusion gets written before anyone checks the signal, the interval, or the gaps. The shortcut is tempting because a visible runtime change can still be incomplete evidence. A screen full of charts may look thorough while lacking the one signal, time window, or unbroken stretch of reports that an explanation depends on. A sparse record makes its limits obvious; a busy record can hide them. That is why the legend asks about the quality of the evidence rather than its volume.
It also helps to keep three kinds of statements separate as you fill in the rows. Some facts come straight from a source document, such as a stated reporting interval. Some reflect widely accepted practice, such as confirming a cause in the field before acting on it. Others vary by installation, such as which sensors a particular station actually has. Writing each statement with its proper weight is what makes the legend trustworthy.
Signal Type: Current Presence Is Not Current Magnitude
Current switches and amp probes provide different kinds of evidence, so identify the installed signal before interpreting any runtime or current-related record.
Does This Station Actually Measure the Value Being Discussed?
The OmniSite current switch indicates whether a motor is running or stopped. That is the presence of evidence: a two-state signal.
The 4-20 mA amp probe documentation describes something different. It covers monitoring and displaying AC motor amperage, which is magnitude evidence. The amp probes are not needed to calculate pump on/off cycles or runtime, but they are required to display pump amperage.
The OmniSite monitoring kits page shows how this distinction appears in documented equipment. The Crystal Ball Plus Kit, as documented, includes two pump amp probes. The XR50 Plus Kit, as documented, includes two pump current switches. These are kit-specific statements. An existing station may have been configured differently, so confirm what is installed before applying either description.
Here is where conversations drift. One person says “pump current” and means amperage. The station records only running and stopped status. Both people are reading the same screen, yet they are describing different evidence.
The practical rule follows directly. If the discussion concerns how long or how often a pump ran, a running/stopped record may be sufficient evidence for the observation. If the discussion turns to amperage, the station needs a measured amperage record, and someone needs to confirm that the record exists for the period in question.
Neither signal type explains behavior on its own. A record can be accurate for the signal it receives and still be unable to answer a different measurement question. That gap is how a detailed-looking report creates false precision. An amperage change is an observation, just as a runtime change is. Same pump, different evidence, and neither one settles the cause.
Reporting Cadence Changes the Visible Detail
Reporting cadence controls the time detail visible in the record, but the space between reports is not continuous analog sampling.
The GuardDog reporting page states that the standard service plan provides a report every 24 hours. The Elite service plan provides 15-minute reporting on analog values, pump calculations, or counters. The Real-time reporting plan provides a 5 minute reporting frequency on analog values, pump calculations, or counters. The Real-Time reporting package also includes the peer-to-peer control feature used for interlocking lift stations and stopping pumps when high-level alarms are triggered.
 Available data and reporting intervals may vary by OmniSite device, connected sensors, and wireless service package.Â
Alarms also belong in their own category. An immediate alarm and a scheduled report are different kinds of records. Unless a specific source establishes how they relate, treat them as separate evidence, and don’t use either one to reconstruct the exact timing or behavior of the other.
Before discussing a runtime change, confirm four facts: the service plan, the device and connected sensors producing the record, the specific report being read, and the date range it covers. Each one changes what the record can say. Time context is part of the evidence, not a display setting.
Record Continuity and Monitoring-Path Warnings
A gap in the record may describe the monitoring path rather than the pump, which means missing data cannot be treated as proof of normal operation or of mechanical failure.
The wastewater monitoring overview describes warnings for weak cellular signals and device reporting failures. Those warnings concern the route data travels from the station to the record. They describe the connection. They do not establish a mechanical pump fault, and they do not confirm that the pump ran normally. Nor do the source materials guarantee that every report will be delivered under every condition, so the evidence stays tied to what the record actually contains.
Continuity directly affects how defensible a maintenance interpretation is. If two daily reports are missing, any trend drawn across that stretch is partly assumption. The pump may have run as usual or it may not have; the record is silent either way.
Federal guidance makes a similar point about records in general. EPA’s guide for evaluating collection system programs treats accurate recordkeeping as the foundation for establishing baseline conditions and identifying problem areas. A baseline with holes in it supports weaker conclusions. EPA’s Smart Sewer Technologies resource likewise discusses the role of system monitoring and operations tools within smart sewer programs.
Timestamps deserve equal attention. When an alarm occurs, when it is received, when someone acknowledges it, and when a scheduled report is generated can be four different moments. If a timestamp’s meaning is uncertain, record that uncertainty in the legend rather than resolving it by assumption. The related subject of event history and data retention requirements covers those distinctions in more depth.
Look-back depth is another variable. GuardDog shows historical data from up to six months ago and upon request can show up to two years of historical data.Â
After hours at a lift station, rain taps the enclosure while wet gloves make an incomplete record awkward to review. Sometimes the obstacle isn’t the data but the setting it gets read in. Under those conditions the most conspicuous alert tends to outweigh the missing timestamps, and waiting for one more alert rarely settles the question.
Treat a gap as a finding. It belongs in the statement.
From Observation to a Bounded Maintenance Interpretation
A defensible interpretation begins by narrowing the claim to what the record directly supports, then identifying the context or confirmation still missing. The order of the steps matters.
State the observation. Write what changed in plain terms, with no cause attached.
Identify the signal. Note whether the record comes from running/stopped status, measured amperage, or another documented input.
Identify the reporting context. Record the service plan, interval, specific report, and date range.
Check continuity. Look for missing reports, monitoring-path warnings, and uncertain timestamps.
State the boundary. Write the narrowest conclusion the evidence supports, and say what it does not support.
Name the open question. Identify what needs appropriate technical or field confirmation.
A team sees that one pump’s recorded runtime changed. Before attributing the change to equipment condition, the team confirms what input produced the record, which reporting interval applies, whether reports are missing, and what local inflow or station context is unavailable. The resulting statement describes the change and its limits without assigning a cause.
Written out, a bounded statement might read like this:
Pump 2’s recorded runtime changed across the last four daily reports. The record reflects running/stopped status, not amperage. Two reports in that range are missing following device reporting failure warnings. The record supports the change; it does not support a cause. Open question: what does a field check at the station show?
That statement contains no threshold, no predicted fault, and no repair recommendation, and the omission is deliberate. The supplied OmniSite documentation does not establish a field-confirmed cause for an unexplained runtime change, so the framework stops at the question rather than answering it. That is a limitation of the supplied evidence, not a claim that monitoring data can never contribute to an investigation.
Stopping there reflects established practice. EPA’s CMOM evaluation guide describes review in three tiers: interviews and observation of routine activities, review of records and information management systems, and evaluation based on field or site review. Records are one tier. The field is another, and the pump data context in a report cannot stand in for it. EPA’s collection and lift station maintenance resource similarly treats operation and maintenance as work supported by appropriate procedures and system-specific practices.
A pump station operations supervisor has 22 minutes before the morning maintenance review. One pump’s runtime is up, two nights of reports are missing, and the record shows running status but no amperage. Arriving with a cause would turn the review into a defense of a guess. Arriving with the bounded statement keeps the meeting focused on what needs checking and who will check it.
How the Three Roles Can Share the Same Evidence
The same evidence can serve all three roles when the handoff separates the observation, its source, its limitations, and the remaining question. The role needs described here are derived from the framework rather than validated through interviews, so treat them as a starting point to adapt.
Maintenance managers gain an evidence-backed frame for maintenance review in which every claim travels with its limits.
Pump station operations supervisors gain a clear record of the signal, the reporting context, and any data gaps before discussion begins.
Collection system managers get consistent, qualified language that holds up when conversations move from one station to the next.
The handoff format keeps all three working from the same five fields:
Handoff field | Required entry |
|---|---|
Observation | What changed, without stating a cause |
Evidence source | The applicable signal, report, and device context |
Time context | Reporting interval, date range, and known continuity |
Limitation | What the record cannot establish |
Open question | What needs appropriate technical or field confirmation |
A useful handoff does not need to sound certain when the evidence is incomplete. It needs to be specific. Rather than reporting that the data tells us nothing, the team names what changed, which signal produced the record, the time context, the missing evidence, and the open question. Every part of that statement then carries a defined evidence status, which makes it stronger than either a guess or a shrug.
Utilities organize this work in different ways. EPA’s guide stresses that a one-size-fits-all approach does not apply, since the same principles may be carried out by different means depending on the system. The handoff format supports a conversation. It does not replace existing response ownership, escalation procedures, or local operational judgment, which are covered separately under lift station alarm requirements, priorities, and escalation.
Monitoring records values and reports them according to the applicable plan. Interpreting those values, deciding what to check, and confirming a cause remain human responsibilities, a distinction explored in defining recurring remote monitoring service coverage.
The limits of this maintenance interpretation framework are worth stating once and clearly. It does not diagnose a pump fault, forecast failure, set universal thresholds, or prescribe repairs. Its source material includes no customer case-study outcomes, field-confirmed causal findings, or interview-validated role behavior. Timestamp semantics, device-version applicability, and local baselines vary by implementation. What it offers three roles is one honest way to describe the same record.
Resources
For public-sector context rather than OmniSite product evidence: EPA CMOM resource for wastewater collection systems
State What the Record Shows and What It Does Not
The phone at the operations desk will buzz again, and some runtime will move again. What changes is the answer you give when someone asks why.
You began with a reading you couldn’t explain and a review that wanted an explanation anyway. Now you can state the observation, name the signal behind it, place it in its reporting context, mark the gaps, and hand over the question that still needs a field answer. That is not uncertainty dressed up as rigor. It is professional accountability: acting on what the record shows and checking what it doesn’t.
The Pump Monitoring Evidence Framework bounds what a changed runtime record can establish. Everything past that boundary is a question for the station.
Disclaimer: This guide is informational. Reporting intervals, available data, and sensor configurations vary by OmniSite device, connected sensors, and wireless-service package, so confirm the details that apply to your stations. Monitoring records support maintenance discussions; they do not replace field confirmation or local operational judgment.
Our Editorial Process:
Our expert team uses AI tools to help organize and structure our initial drafts. Every piece is then extensively rewritten, fact-checked, and enriched with first-hand insights and experiences by expert humans on our Insights Team to ensure accuracy and clarity.
By: The OmniSite Insights Team
The OmniSite Insights Team is our dedicated engine for synthesizing complex topics into clear, helpful guides. While our content is thoroughly reviewed for clarity and accuracy, it is for informational purposes and should not replace professional advice.