Most RFID projects are scoped as installations and then judged as operations. The acceptance test proves that the hardware worked on the day the integrator left. What decides whether anyone still trusts the system eighteen months later is something else: whether a degraded dock-door antenna, a backing-up middleware queue or a drifting count is visible within minutes rather than at the quarterly audit.

Monitoring is not a dashboard bolted on at the end. It is the mechanism that turns a one-off deployment into an asset with a measurable service level, and it is the difference between a system that quietly decays and one that is repaired before users notice.

Monitoring starts the day after go-live

Project plans usually end at acceptance. The operating plan should begin there, with a named owner and a defined service level.

Every reader, antenna, switch port and middleware node needs an owner, even when that owner is a role rather than a person.
Define what healthy means in numbers before the first incident, not while it is happening.
Publish a service level the business can hold you to: read rate, latency and reconciliation gap.
Budget operating cost, including spares, at the same time as capital cost. Spares are what turn a two-day outage into a two-hour one.
Record the baseline measured at acceptance. Without it, no later degradation can be proven.

Three layers, three failure classes

RFID monitoring fails when it watches only the hardware. The failures that hurt are spread across three layers, and each layer needs its own instrumentation.

Device layer: reader connectivity, antenna status, transmit and reflected power, temperature, and the success rate of the read specifications running on the device.
Middleware layer: raw event throughput, throughput after deduplication, dispatch latency and queue depth.
Business layer: read rate on the processes that matter, reconciliation gap against the ERP, and end-to-end latency from tag to record.
Device failures are visible and loud. Middleware failures are quiet. Business failures are silent until somebody trusts the wrong number.
A reader that is online and transmitting while its read rate has fallen to 70 % is a business failure that device monitoring will never catch.

Eight metrics worth alerting on

A short list that is actually acted on beats a wall of charts. These eight cover most of what goes wrong in production.

Read rate: warn below 99 %, page below 95 %. Measure per portal and per process, never as a site average.
Reader reconnections: warn above two per day, page above five. Frequent reconnects usually mean cabling, PoE budget or firmware.
Raw event throughput: warn at 30 % below the seven-day average, page at 50 %. This is the earliest signal of a dead antenna.
Queue backlog: warn above 1,000 events, page above 10,000. Backlog is the leading indicator of data loss.
End-to-end latency: warn above two seconds, page above five. Latency matters most at the dock, where an operator is waiting.
Reconciliation gap: warn above 0.1 %, page above 0.5 %. This is the number finance will ask about.
Reader temperature: warn above 60 °C, page above 70 °C. Heat is the slow killer of fixed readers in unventilated back rooms.
Tag inventory accuracy at the cycle count: warn below 99.5 %, page below 99 %. Below that, the count is a rumour.

Thresholds should be tiered and tied to a response time: warnings answered within four hours, pages within thirty minutes, with automatic escalation to the on-call engineer. A threshold nobody answers is worse than no threshold, because it teaches the team to ignore the dashboard.

Device layer: readers, antennas and LLRP

The device layer is the easiest to instrument and the most tempting to over-instrument. Focus on what precedes a failure.

Track the LLRP connection state per reader, not just whether the IP address answers a ping.
Monitor transmit power and reflected power per antenna. A rising reflection coefficient usually means water ingress or a damaged cable.
Log the execution result of every read specification. A specification that stops being re-armed is a silent outage.
Watch the reader clock. A drifting clock produces events with wrong timestamps, and those events will be rejected downstream.
Keep firmware versions in the asset inventory. Mixed firmware across one site is a common cause of intermittent, unexplainable behaviour.

Middleware layer: the event pipeline

Middleware is where good reads become bad records, so it deserves its own metrics.

Measure raw events per second and events per second after deduplication. The ratio tells you whether the filters are working or the tag population has exploded.
Track dispatch latency to the ERP including retries. A retry storm looks like throughput until the queue fills.
Instrument the dead-letter queue. Every rejected event should be inspectable with its payload and its reason.
Monitor connector health separately from reader health. The reader can be perfect while the connector is throttled.
Alert on configuration drift. A middleware node edited by hand during an incident is a future outage.

Business layer: read rate and the reconciliation gap

This is the layer the business cares about and the one most often missing.

Define read rate per process: receiving, put-away, picking, shipping, cycle count. A single site-wide figure hides the broken process.
Compute it from the ERP side, not from the reader's own count. The reader counts what it heard; the ERP knows what should have been there.
Measure the reconciliation gap daily and trend it weekly. A gap that grows slowly is a design problem; a gap that jumps is an incident.
Track end-to-end latency from the physical read to the record the operator sees.
Report a monthly summary in business language: what was missed, what it cost and what changed as a result.

Logs, trace IDs and thirty-minute localisation

Logs are the last line of defence, and their value depends almost entirely on being joinable.

Standardise on one structured format, one timestamp in UTC and one trace identifier carried across every system.
Capture four log families: reader, middleware, ERP integration and business outcome.
Retain at least ninety days hot and a year cold. Many incidents are explained by an event three weeks earlier.
Make the trace identifier visible on the operator screen, so a user reporting a problem can hand over the exact reference.
Practise localisation. A team that has never run a fault drill will spend hours finding something it could have found in minutes.

The operating cadence and the road to autopilot

Operations is a loop, not a help desk. The cadence is what turns incidents into improvements.

Weekly: review the past week's alerts and incidents, classify root causes as hardware, software, environment or human, and agree the fixes.
Monthly: deep-dive the three most frequent fault types and close them at design level rather than at ticket level.
Quarterly: review hardware health, mean time between failures and the replacement budget, and evaluate middleware upgrades.
Track two outcome numbers: mean time between failures and mean time to repair. A mature site reaches thirty days and thirty minutes respectively.
After six to twelve months of disciplined operation, the labour required typically falls to a fraction of a full-time role and the system runs close to unattended — provided the loop was really run.

A monitored RFID system is not one that never fails. It is one that fails visibly, briefly and without surprising the business.