IoT Monitoring Alert Guide

Interpret floor-level Cisco Spaces IoT monitoring alerts and decide what to investigate next.

What the alert covers #

The alert summarizes Cisco Spaces IoT health for a configured building or building-equivalent network. A monitoring configuration cannot be assigned to a floor; monitoring fetches building-level data and groups results by floor. Each table row represents one of those floors and the TOTAL row summarizes the full configured scope.

Table and count columns #

Generic monitoring alert example
|                     |     |            IOx App            |            Beacon            |    Sync    |
|Floor                | APs | Noncomp. | N | O | C | Alrt | Noncomp. | N | O | C | Alrt |  Bad   | State | Alert
|---------------------+-----+----------+---+---+---+------+----------+---+---+---+------+--------+-------+------
|Example Floor A      |  44 | 6 (14%)  | 2 | 3 | 1 | ❌   | 5 (11%)  | 1 | 1 | 3 | ❌   | 0 (0%) | ✅    | ❌
|Example Floor B      |  22 | 2 (9%)   | 0 | 0 | 2 | ⚠️   | 1 (5%)   | 0 | 0 | 1 | ⚠️   | 0 (0%) | ✅    | ✅
|TOTAL                |  66 | 8 (12%)  | 2 | 3 | 3 | ❌   | 6 (9%)   | 1 | 1 | 4 | ❌   | 0 (0%) | ✅    | ❌

For count columns, zero is good. APs is the floor inventory. Noncomp. is the affected AP count and percentage. N means newly noncompliant, O means an older condition, and C means a configuration or not-evaluable issue.

Sync Bad identifies recent channel values that disagree. Alert is the overall floor result.

Values and icons #

A value such as 1 (2%) means one affected AP, representing two percent of the inventory on that floor. Percentages are relative to the floor, not the full building or network, so a concept can be healthy on one floor and critical on another.

  • ✅: no issue for the concept on that floor.
  • ⚠️: issues exist but remain below the configured threshold.
  • ❌: the floor breached the configured threshold.
  • 🚧: alerting is suppressed for maintenance while data remains visible.

Follow-up guidance #

  • Start with floors showing a red overall Alert icon.
  • IOx and beacon failures on the same floor are stronger evidence of a floor-wide issue.
  • A large C count usually indicates configuration or not-evaluable evidence that needs review.
  • Contradictory or stale evidence is a data-quality issue and must not be treated as synchronized state.

How monitoring classifies evidence #

Dimension Values Example
Configuration status compliant, noncompliant, unknown An unknown runtime gateway value is unknown, not Base Gateway.
Operational status healthy, degraded, unknown An offline AP or an installed-but-DOWN Cisco BLE IOx app is operationally degraded.
Data quality consistent, incomplete/stale, contradictory Correct configuration with stale telemetry remains a data-quality issue rather than a clean result.

Monitoring, the IoT configuration table, and remediation audit use the same normalization and compliance evaluator. Unrelated IOx applications are not treated as the Cisco BLE application, and contradictory endpoint evidence is reported as unknown rather than synchronized.

Inventory drift #

/api/edm/v1/device/ap is the authoritative observed AP inventory. Where published intent exists, execution detail lists observed APs without published rows and published APs missing from observed inventory. Inventory drift is informational: it does not trigger an alert by itself, but it is appended to alerts caused by other findings and included in the daily digest.

Detailed execution report #

  • Run Summary: tenant, account context, monitored location, timestamps, and status.
  • Current Totals: AP inventory and current IOx, radio, beacon, and connector counts with previous-run values.
  • Connector Overview: per-connector and per-instance node, channel, service-manager, IoT-service, and API issue state.
  • Alert Delivery: sent, suppressed, partially delivered, or failed state with per-destination detail.
  • Flagged Issues: detected events followed by floor-level new and existing/configuration issues with expandable raw AP detail.
  • Captured Tracebacks: collection and processing exceptions grouped by source.
  • Stored Result Payload: persisted JSON for advanced troubleshooting and engineering review.

Start with Flagged Issues for AP-level triage and Captured Tracebacks for collection or API failures.

IOx App Down is based on IOx application channel timing. It does not necessarily mean that the AP itself is powered off or unreachable.

Triage first

The alert is a high-level triage tool. The execution report remains the source of full monitoring detail for the run.