Meraki DataMagic - Wireless Health

The Wireless Health page shows Meraki wireless-health measurements for the wireless networks within the selected Estate node. Meraki calculates these health figures in two-hour windows; DataMagic collects and keeps every window, so you can see how a network's radio quality, client-connection success and performance change over time rather than just the latest snapshot.

Each row is a single measurement: one metric (for example RF score or Latency) with its value for one two-hour period. A network therefore contributes several rows per period - one for each metric it reports, one per band for radio metrics, and one per access point for the per-access-point metrics (packet loss and channel utilisation).

Finding the page

Open Wireless Health from the Meraki Estate menu. The page opens on the whole retained history (about the last 60 days) for whatever is currently selected in the Estate tree.

Choosing what you see - the Estate tree

Use the Estate tree to set the scope. Selecting an organization, network group or network filters the table, the timeline and the chart to just that part of the estate; the Org, Group and Network columns hide themselves once they are implied by the selection. Most metrics are network-level, but two - packet loss and channel utilisation - are measured per access point, so selecting an individual access point narrows the data to just that access point's measurements. (The network-level metrics - RF, the connection funnel, latency and data rate - appear when a network is selected, not an access point.)

The metrics

Every metric belongs to one of Meraki's wireless-health sections, shown in the Category column. Radio metrics are reported per band; the client-connection metrics are network-wide; and the performance metrics are network-wide too, except packet loss and channel utilisation, which are measured per access point.

Metric	Category	What it measures	Per band?
RF score	RF	Meraki's overall radio-quality score, 0-100. Higher is better.	Yes
High CCI %	RF	Percentage of the window with high co-channel interference. Lower is better.	Yes
Channel changes	RF	How many times the radio changed channel in the window. Fewer means a more stable radio environment.	Yes
Association / Authentication / DHCP / DNS failures	Connection	Client join attempts that failed at each step of connecting: association, 802.1X / RADIUS authentication, obtaining a DHCP lease, and DNS resolution.	No
Successful connections	Connection	Client connections that completed successfully in the window.	No
Clients considered / connected / stuck at a stage	Connection	The client-based view of connecting: how many clients were seen trying to connect, how many succeeded, and how many never connected because they were left stuck at association, authentication, DHCP or DNS. Counts clients rather than attempts, so a device retrying in a loop counts once.	No
Latency	Performance	Average data-plane latency for the network, in milliseconds. Lower is better. Idle periods with no traffic are excluded so the figure reflects latency while the network was in use.	No
Data rate (download / upload)	Performance	Average downstream and upstream PHY data rate for the network, in kilobits per second.	No
Packet loss (downstream / upstream)	Performance	Average percentage of frames lost downstream and upstream for an access point over the window. Lower is better.	No
Channel utilisation	Performance	Average percentage of time the channel was in use for an access point over the window. Higher means a busier, more congested channel.	Yes
SNR (signal-to-noise ratio)	Performance	Average signal-to-noise ratio for an access point over the window, in dB. Higher is better.	No
RSSI (signal strength)	Performance	Average received signal strength for an access point over the window, in dBm (a negative value; closer to zero is stronger).	No

Values are the raw measurement only - there are no stored "good / bad" ratings, so you are free to judge them against your own thresholds.

The timeline

A slim timeline sits above the table. Each bar counts how many measurements exist in that period, giving a quick sense of coverage across the retained history. It also acts as the date-window selector: drag to select a range, or use the zoom and scale controls to move between Hours, Days, Weeks and Months. The table and the chart both follow whatever window the timeline is showing.

The chart

Below the timeline, a collapsible chart plots one metric across the selected window. Choose the metric from the dropdown - a short note beside the selector reminds you what each one shows:

• Connection funnel - a stacked bar per period showing successful connections against the association, authentication, DHCP and DNS failures, so you can see where clients drop out of the join and how that changes over time.
• Connection steps - a single snapshot for the whole selected window: an area line showing the percentage of clients that successfully complete each stage of connecting (association, authentication, DHCP, DNS, then overall success). The line drops wherever clients fail, so it is easy to see exactly which stage is the problem. The scale is fixed at 0-100% so different networks can be compared directly, and each point is labelled with its percentage.
• Client connection - a stacked bar per period, like the connection funnel, but counting clients rather than attempts: how many clients connected against how many did not. Because it counts clients, a device retrying in a loop counts once, so it cannot dominate the picture the way it can in the attempt funnel. This is the trend behind the Connection figure on the health overview.
• RF score and High CCI % - a line, averaged across the network's bands, so the trend is easy to read. RF score is shown on a fixed 0-100 scale.
• Channel changes - a bar per period counting radio channel changes.
• Latency - a line of average latency in milliseconds.
• Data rate - two lines, download and upload, in kilobits per second.
• Packet loss - two lines, downstream and upstream loss as a percentage. Measured per access point: with a network selected the lines are the average across that network's access points; select a single access point to see just that one.
• Channel utilisation - two lines, one per band (2.4 and 5 GHz), as a percentage, again per access point. Pinned to a fixed 0-100% scale.
• SNR - a line of average signal-to-noise ratio (dB) per access point; higher is better.
• RSSI - a line of average received signal strength (dBm) per access point. Values are negative - closer to zero is a stronger signal - so the line sits below zero.

Counts (the connection funnel, channel changes) are drawn as bars; continuous values (RF score, interference, latency, data rate) are drawn as lines; and the connection-steps funnel is an area line. The chart tracks the timeline's date window and any search you have applied. Collapse it with the Chart heading when you want more room for the table.

The table

The table lists the individual measurements for the selected window and scope. Its columns are:

Column	Description
Org	The Meraki organization the measurement belongs to. Shown when the Estate scope is above organization level.
Group	The network group the network is in.
Network	The Meraki network the measurement is for. The Meraki icon opens the network in the Meraki dashboard.
Access Point	The access point the row measures, for the per-access-point metrics. Shown as "--" for network-wide metrics, and hides itself once you have drilled into a single access point.
Network Meraki Id	Meraki's own identifier for the network - copy it to cross-reference in the Meraki dashboard. Shown in the Identity column group.
Serial	The access point's Meraki serial - copy it to cross-reference in the Meraki dashboard. Shown in the Identity column group.
Device MAC	The access point's MAC address. Shown in the Identity column group.
Date/Time (UTC)	The start of the two-hour window the measurement covers.
Band	The radio band in GHz (2.4 / 5 / 6). Shown as "--" for network-wide metrics such as the connection funnel, latency and data rate, which are not band-specific.
Metric	Which wireless-health metric the row measures. Hover the value for its definition.
Value	The measured value for the metric in that window.
Category	The Meraki health section the metric belongs to (RF, Connection, Performance). Hover the value for what it covers. Shown in the Detail column group.
Interval (s)	The size of the source window in seconds (7200 = two hours). Shown in the Detail column group.
Created UTC	When DataMagic first stored this measurement row. Shown in the Updated column group.
Last Modified UTC	When the row was last updated. Wireless-health rows are written once per two-hour window, so this normally matches Created. Shown in the Updated column group.

The columns are organised into groups: use the Columns selector above the table to switch between All, Identity (the Meraki id, serial and MAC), Detail (category and interval) and Updated (when the row was created and last modified). Type in the search bar to search across network name, Meraki id, access point name and serial, metric and band, or use the column filters - Band, Metric and Category each offer a select-all filter list. Hovering a Metric or Category value shows a one-line definition. Double-click any row to open a detail panel with its measurement, network and access-point details.

How it works

A DataMagic collector runs for each organization roughly every two hours. For each wireless network it asks Meraki for the health figures covering the most recently completed two-hour window and stores them as (metric, value) rows stamped with that window's start time, so every metric lines up on the same two-hour grid. The per-access-point figures - packet loss and channel utilisation - are collected the same way and stored against the individual access point. Collection is resumable and gap-free: each network remembers how far it has been collected, so a restart never double-counts and never skips a window, and a network that is temporarily unavailable simply catches up on the next run.

Measurements are kept for about 60 days and then aged out automatically, which is why the timeline reaches back roughly two months.