DHCP Pool Usage Inconsistency Between Dashboard and API Response

[LucasLe]

Hi everyone,

I'm reporting an issue where the DHCP pool usage data shown on the Meraki Dashboard does not match the data returned by the API. This inconsistency is causing problems for our automated network monitoring workflows.

[olasupoo]

Hi Lucas,

Looking at your two screenshots, the deltas point to a couple of different things rather than one bug, so worth separating them.

Subnets 1 and 2 are off by exactly one (0 vs 1 used, and 11 vs 10), in opposite directions. That's just timing — DHCP usage is a live count, and the dashboard snapshot and the API call were taken moments apart, so a single lease coming or going between the two explains it. That part isn't a fault.

Subnet 3 is the real outlier — 34 used on the dashboard vs 17 from the API. That's too big for timing, and there are two usual causes:

Per-appliance scope. GET /devices/{serial}/appliance/dhcp/subnets returns the lease state for that one serial. Check two things: that the serial in the call is the same MX you're viewing in the dashboard (easy to grab the wrong one in a multi-MX org), and if this is a warm-spare HA pair, that you're hitting the active unit — the spare mirrors leases over UDP 3483 but can lag briefly during sync.

Counting semantics. The dashboard "Used" figure can include fixed-IP (reserved) assignments and leases that are expiring but not yet purged, whereas the API usedCount reflects currently-active leases. A gap of 17 fits that kind of difference — worth checking whether that subnet has around 17 fixed IP assignments configured.

For the monitoring workflow, the cleaner approach is to treat the API as your single source of truth and poll it directly rather than diffing it against the UI — the dashboard caches and refreshes on a different cadence, so small mismatches are expected and shouldn't drive alerts.

If you sample the dashboard and the API at the same instant, against the same active serial, and subnet 3 still shows that 17-address gap — then it's worth a support case with both payloads, the serial, and timestamps, since at that point it isn't explained by timing or scope.

[LucasLe]

Thanks for the detailed breakdown. Let me provide some additional context about our current environment:

We have only a single MX — no warm-spare HA pair.

The MX serial passed to the API is the exact same serial displayed on the Dashboard.

No fixed/reserved IP assignments are configured on the affected subnet3 VLAN's DHCP scope.

Regarding timing: the API call and the Dashboard snapshot were captured at the same instant.

From what we've observed in practice, the second VLAN is dedicated to Meraki network devices — there are 8 MR access points and 3 MS switches on that network, which aligns exactly with the DHCP pool usage shown on the Dashboard. So there's good reason to believe the API response itself is returning incorrect data.

[olasupoo]

Hi Lucas,

Based on your feedback, I will rule out HA, serial, reservations and timing.

However, one thing in your own data argues against the API simply under-counting:

Subnet 1 shows 0 used on the dashboard but 1 on the API — there, the API reports more, not less. If it were just dropping leases you wouldn't see that. So the two figures look like they're counting different things rather than one being uniformly wrong.

The API usedCount is active DHCP leases in the pool, while the dashboard "Used" reflects the IPs it observes consumed on the subnet — and those can diverge in both directions.

That also reframes the subnet 2 match. 11 devices lining up with the dashboard's 11 is suggestive, but Meraki APs and switches on a dedicated management VLAN are very often statically addressed, so "11 devices present" doesn't necessarily mean "11 active DHCP leases." The API's 10 could be the correct lease count if one of those 11 isn't actually leasing. Subnet 2 is consistent with either reading — it doesn't settle it.

So before calling it an API bug, I'd get a third, independent count for subnet 3, since right now both numbers are assumptions:

• Pull the actual lease/client list for that VLAN — Dashboard → Clients filtered to the subnet, or the clients API — and count how many genuinely hold a lease.
• If that comes back around 34, the API's 17 is genuinely wrong. If it comes back around 17, it's the dashboard tile that's stale, not the API.

If the independent count confirms ~34 active leases while the API still returns 17 at the same instant on the same serial, that's a clean one to raise with support — attach both payloads, the dashboard, the lease list, the serial and timestamps, and call out the subnet 1 inversion too. That combination is what shows their engineering it's a data-accuracy issue and not config.