Home › Learn

Why does CMDB location data go stale?

By Thaddeus Stepanovich — Founder, Harbinge.rs · 14 years in EMS and healthcare IT

How fast does location data actually drift?

Drift doesn't happen on a schedule. It happens at ticket time, at project time, and — more often than anyone wants to admit — informally, when someone grabs a workstation on wheels from the hallway because it's closer than the one assigned to their unit. None of those moments are database events. They're physical events that a database only learns about if a person separately decides to open a form and type in a new room number.

That's the mechanical root of the problem: a location record is only as fresh as its last confirmed touch, and confirmation is not a byproduct of anything else your organization already does. A ticket gets closed when the printer works again, not when someone verifies which closet it's actually sitting in. A device gets reassigned in a hallway conversation, not in the asset management system. Each of these is a small, individually reasonable shortcut. Compounded across thousands of assets and hundreds of staff over months, they add up to a database that increasingly describes a building that no longer exists.

You'll see plenty of published statistics claiming CMDBs are some fixed percentage inaccurate — 20%, 30%, sometimes higher. Treat those numbers skeptically; they vary wildly by study, by asset class, and by how "accuracy" was defined in the first place, and none of them transfer cleanly to your environment. The more useful way to think about drift is mechanical, not statistical: the rate of decay is a function of how many assets move, how often they move, and how many of those moves have zero built-in mechanism for getting logged. In a hospital, a mobile-heavy environment with high staff turnover and constant equipment reassignment, that rate is high by default — not because anyone is being careless, but because the physical world moves faster than any manual process can track it.

What does "CMDB accuracy" actually measure?

"Accuracy" is doing a lot of unexamined work in most conversations about configuration management. It's worth splitting it into three distinct questions, because they decay at completely different rates and require completely different fixes:

Location is the perishable one. A serial number doesn't change when a cart rolls from 3-West to 4-East; the location field does, and it does so silently unless someone deliberately updates it. This is why an organization can have a CMDB that looks healthy by every other measure — clean intake records, correct model numbers, accurate warranty data — and still be functionally unusable for the one question a technician, a compliance officer, or an incident responder actually needs answered in the moment: where is this thing right now?

Why don't audits and spreadsheets fix it?

The standard answer to "our CMDB is wrong" is a wall-to-wall inventory: send teams floor to floor, scan or eyeball every asset, reconcile the spreadsheet against the database, and call it corrected. This works, briefly. The trouble is what a wall-to-wall inventory actually is: a single snapshot in time, taken at significant labor cost, that begins decaying the moment it's finished. See our breakdown of wall-to-wall inventory economics for the full cost math, but the short version is that most organizations can only justify this exercise annually or semi-annually, which means the database is accurate for a matter of weeks and then resumes its slow drift back toward fiction for the other eleven months.

Spreadsheets fail for a related but distinct reason: they have no mechanism for detecting their own staleness. A spreadsheet cell doesn't know it's wrong. It sits there looking exactly as authoritative the day after an audit as it does eleven months later, with nothing in the interface distinguishing a confirmed-yesterday location from a confirmed-last-year one. Without a timestamp attached to every record — and without something forcing that timestamp to refresh — a spreadsheet or a CMDB field is a snapshot pretending to be a live feed.

The fix isn't a better audit cadence. It's changing what triggers an update in the first place.

What are the ways to keep location data current?

Setting aside the annual-audit approach already covered above, there are three broad strategies for keeping location data closer to real time, and each trades cost against reliability differently.

Process discipline. Train staff to update the CMDB whenever they move or discover a moved asset, and enforce it through policy. This is cheap to implement — it requires no new infrastructure — but it's fragile in exactly the way manual processes always are: it depends on every person, every time, remembering to do an extra step that has no immediate payoff for them personally. It degrades fastest under staff turnover, high ticket volume, and short-staffed shifts — which, not coincidentally, is when accurate location data matters most.

Continuous real-time location systems (RTLS). Tag every asset and deploy fixed infrastructure — Wi-Fi, BLE, or UWB anchors — to track location automatically and continuously. This genuinely works: once installed, it removes the human update step almost entirely. The tradeoff is infrastructure cost and complexity. Anchor installation, tag procurement, ongoing calibration, and IT overhead put continuous RTLS out of reach for a lot of mid-sized facilities and non-clinical asset classes. See how RTLS actually works for the underlying mechanics and cost drivers.

Attestation-based confirmation. Instead of continuous tracking or a separate manual update step, location gets confirmed as a side effect of work someone is already doing — closing a ticket, servicing a device, walking a floor for an unrelated reason. No fixed infrastructure, no dedicated update ritual to forget; the confirmation happens because the task required physically being at the asset anyway. The tradeoff is that coverage is only as good as how often each asset gets touched by normal work, so infrequently serviced assets still go stale between touches. For a deeper comparison against full RTLS, see RTLS alternatives.

None of the three is free. Process discipline is cheap and unreliable. Continuous RTLS is reliable and expensive. Attestation-based confirmation sits in between — cheaper than infrastructure, more durable than a policy memo, because it attaches the update to an action someone was already going to take.

Where Forager fits

Forager is built around the attestation model described above. When a technician closes a ticket, services a device, or walks a floor during a Remediation Sprint, confirming that asset's location takes about ten seconds against the building's floor plan — no separate CMDB update task, no dedicated scanning pass. That confirmation is timestamped, attributed to the technician, and pushed to your CMDB or ServiceNow instance automatically.

Because every confirmation is compared against the last known record, Forager also flags mismatches the moment they surface — an asset scanned in a location that contradicts what the database currently says gets surfaced for review rather than silently overwriting or silently persisting as an error. Over time this produces an attestation trail: a running, exportable log of who confirmed what, where, and when, which is the same record that answers a Joint Commission surveyor's location question or an incident responder's device inventory request in minutes instead of days.

Forager doesn't replace process discipline or rule out RTLS where continuous tracking is genuinely warranted — it's a lower-cost way to keep the location field honest for the large majority of assets that don't need centimeter-level real-time tracking, just a record that's never more than one normal workday out of date. See how Forager works.