Skip to content

Lift Stations and Sewer Network Telemetry

Lift-station telemetry is a high-value field-connectivity problem because the cost of weak visibility is immediate. Overflow risk, pump health, wet-well level, power loss, and sparse service windows all push teams toward architectures that are simple, durable, and easy to recover when the site is unattended. Buyers in this category are not looking for novelty. They are looking for timely alarms and enough field truth to avoid unnecessary emergency visits.

Most lift-station telemetry systems should start with a conservative design: one durable field controller or telemetry gateway, one cellular path unless the site consequence is unusually high, local alarm handling with event buffering, and very disciplined reporting behavior. The goal is not constant chatter. It is dependable alarm visibility plus enough trend and status data to support operations. If the architecture needs heavy compute, continuous polling, or complex network customization before the first site is live, the design is probably overshooting the job.

What a useful lift-station telemetry system actually needs

Section titled “What a useful lift-station telemetry system actually needs”

For most unattended sewer and wastewater assets, the first-phase system should be able to answer:

  • is the site healthy right now;
  • is the wet well rising abnormally;
  • did power drop or recover;
  • did a pump fail to start, short-cycle, or run too long;
  • can the system preserve and forward events after a communications interruption.

That is enough to create operational value. It is not necessary to turn the site into a miniature datacenter.

Public hardware and connectivity snapshot checked April 4, 2026

Section titled “Public hardware and connectivity snapshot checked April 4, 2026”

These public prices are useful because they show how modest the connectivity layer can be relative to truck rolls and incident response:

Public listing or planPublished price snapshotWhy it matters
Digi IX10-00G4 industrial cellular router on DigiKey$419.00A real industrial cellular boundary device does not have to start in the four-figure range
Banner DXM1200-X2 IIoT gateway on DigiKey$637.00A telemetry gateway with local logic and field I/O integration is still a manageable capital item
Hologram pricing$3 SIM, $1 monthly recurring charge, and $0.03 per MB on the self-service planA low-data site can keep recurring cellular cost very low if reporting is disciplined
Telnyx IoT pricing$1 SIM, $2 monthly recurring charge, and usage from $0.078 per MB for the first 100 MBA second public benchmark for low-data cellular economics

Those figures matter because they clarify something important: in lift-station telemetry, recurring connectivity is often not the expensive part. Misconfigured alarming, weak site power, and avoidable field visits are usually more expensive than the SIM bill.

What the monthly data bill often looks like

Section titled “What the monthly data bill often looks like”

If a site is engineered to report by exception and transmit moderate trend data, it might use only tens of megabytes per month. At 20 MB per month:

  • Hologram is roughly $1.60 per month in usage plus the $1 MRC, before taxes and extras;
  • Telnyx is roughly $3.56 per month including the $2 MRC at the published first-tier usage rate.

That does not mean every utility should choose those plans. It does mean network behavior and alarm discipline often matter more than raw carrier cost.

The cleanest lift-station pattern is:

  1. local collection of wet-well level, pump status, power state, and alarm conditions;
  2. local alarm prioritization and event logging;
  3. cellular backhaul with store-and-forward behavior;
  4. remote dashboarding and notification tuned around alarms, not around constant traffic;
  5. enough local observability that a field technician can understand the site quickly.

This is why lift-station telemetry is as much an operations-design problem as a networking problem.

The common mistakes are:

  • treating every measurement change as an event worth transmitting;
  • overcomplicating the network layer before site power and surge protection are stable;
  • assuming more telemetry volume automatically improves decision quality;
  • designing the dashboard without field-recovery context;
  • forgetting that the site may be serviced by technicians who did not help commission it.

These are not minor issues. They directly affect whether the system becomes trusted or ignored.

Hardware selection should follow field reality

Section titled “Hardware selection should follow field reality”

Use a lighter cellular boundary when:

  • the job is mostly alarming and a handful of telemetry points;
  • local logic is simple;
  • the plant wants a replaceable, supportable field unit.

Use a richer telemetry gateway when:

  • more I/O integration is needed;
  • local event handling and data conditioning matter;
  • the site may aggregate multiple field devices or sensors.

The published prices above show that both options can still be modest relative to integration labor and service cost. That is why the device class should be chosen for fit, not prestige.

The real economic driver: avoided field cost

Section titled “The real economic driver: avoided field cost”

One unnecessary after-hours site visit can exceed several months of connectivity cost. That is why a durable telemetry design should optimize for:

  • meaningful alarms;
  • buffered event history after outages;
  • quick field diagnosis;
  • low-noise reporting that keeps operators attentive.

If the telemetry layer is noisy, the utility still pays the operational cost even if the hardware was inexpensive.

The design is ready when:

  • alarm priorities are defined before dashboarding is polished;
  • local buffering exists for communications loss;
  • cellular cost has been estimated using realistic low-data assumptions;
  • device choice matches the site’s actual telemetry and I/O burden;
  • field technicians can recover basic site state without calling the original integrator.

If several of those are still unclear, fix the field model before scaling the fleet.