Cisco Spaces OS Day 2 Guide

INTRODUCTION

This guide helps Cisco Spaces administrators keep a Cisco Spaces OS deployment healthy after the initial setup is complete. Use it for routine monitoring, maintenance, troubleshooting, and support escalation across the Cisco Spaces platform foundation.

The guide assumes that Cisco Spaces OS has already been deployed using the Cisco Spaces OS runbook and that the required wireless, map, connector, integration, and API components are in production.

SCOPE

Use this guide to operate and troubleshoot:

• Cisco Spaces tenant and admin access

• Cisco Spaces Connector instances

• Connector control and data channels

• Catalyst wireless controller and Catalyst Center integrations

• Meraki network and map integrations

• Webex device integration

• Location hierarchy and digital maps

• Location, IoT, and local Firehose services on the connector

• API keys and downstream integrations

• Support case preparation and escalation

This guide does not replace the deployment runbook. For initial onboarding, feature enablement, or design prerequisites, use the Cisco Spaces OS runbook.

OPERATIONAL OUTCOMES

A healthy Cisco Spaces OS environment should provide these ongoing outcomes:

• Cisco Spaces administrators can sign in and manage the tenant.

• Each production connector is online and shows healthy control and data-channel status.

• Wireless controllers and networks continue sending the expected telemetry.

• Catalyst Center, Meraki, and Webex integrations remain synchronized.

• Location hierarchy, floors, AP placement, and maps stay current after site changes.

• IoT Services, Location Services, and Local Firehose operate as expected where enabled.

• API keys and downstream integrations are valid, owned, rotated, and monitored.

• Operational teams can detect, triage, and escalate service-impacting issues quickly.

MONITORING MODEL

Use the built-in Cisco Spaces dashboards as the primary monitoring surface, and supplement them with connector-local monitoring when the deployment needs external alerting.

CONNECTOR HEALTH MONITORING API

For deployments that use external monitoring, configure the monitoring platform to poll the connector-local monitoring endpoint:

GET https://<connector-fqdn-or-ip>/api/connector/v1/monitoringdata
Authorization: Bearer <connector-api-key>

Generate the API key from the connector user interface and store it in the monitoring platform as a secret. Do not embed the key in scripts, tickets, or shared documentation.

Monitor at least these signals:

Start with conservative thresholds based on the site's normal weekday and weekend patterns. After two to four weeks, tune thresholds so alerts identify real degradation without creating noise.

ROUTINE OPERATIONS

Daily Checks

1. Open Cisco Spaces and confirm the tenant loads normally.

2. Review connector status for each production connector.

3. Confirm control-channel and data-channel status are healthy.

4. Check the connector dashboard for CPU, memory, disk, and service health.

5. Review wireless controller status and verify the expected controllers are active.

6. For deployments using IoT Services, review the IoT Services dashboard and detailed status pages.

7. For deployments using Local Firehose, confirm events are flowing to the downstream receiver.

8. Check recent alert tickets or monitoring alerts and compare them with any planned change windows.

Weekly Checks

1. Review Catalyst Center, Meraki, and Webex integration status.

2. Confirm recently added or changed sites, buildings, floors, APs, and maps are reflected in Cisco Spaces.

3. Review API key ownership and confirm new keys were created through the approved change process.

4. Check connector service metrics for unusual data-rate, location-rate, or resource trends.

5. Verify that alert recipients and operational ownership are still current.

Monthly Checks

1. Review connector software and service versions against the supported deployment standard.

2. Validate connector host capacity against current controller, AP, client, IoT, and Firehose volume.

3. Review stale admins, stale API keys, and unused integrations.

4. Confirm maps and AP placement remain aligned to facilities changes.

5. Confirm support contacts and escalation paths are current.

6. Review recurring incidents and convert repeated manual fixes into monitoring, automation, or change-control improvements.

After-Change Checks

Run these checks after wireless controller upgrades, Catalyst Center changes, Meraki changes, Webex authorization changes, SSO changes, map imports, connector upgrades, firewall changes, or API key rotations.

1. Confirm Cisco Spaces sign-in and role access.

2. Confirm connector online status and control/data-channel health.

3. Confirm expected controllers, APs, floors, and maps remain visible.

4. Confirm integration sync has completed.

5. Confirm IoT Services, Location Services, Local Firehose, and API consumers are still receiving expected data.

6. Record the validation result in the change record.

MAINTENANCE TASKS

Connector Maintenance

1. Maintain an inventory of each connector, including hostname, IP address, site ownership, monitored controllers, services enabled, and operational owner.

2. Review connector health before and after upgrades or host maintenance.

3. Keep connector access limited to approved administrators.

4. Rotate connector-local API keys through the approved change process.

5. Download diagnostics before disruptive troubleshooting when a connector is degraded and support escalation may be needed.

6. Keep connector resource sizing aligned to the production telemetry volume.

Integration Maintenance

1. Document the owner, purpose, credential type, and renewal process for each integration.

2. Review integration health after source-system changes.

3. Remove unused integrations and disable unused API keys.

4. Keep integration credentials and API keys out of shared tickets and runbooks.

5. Validate downstream consumers after any key rotation, receiver change, or firewall change.

Location and Map Maintenance

1. Treat location hierarchy and digital maps as operational data that must be maintained after site changes.

2. Reconcile new, renamed, moved, or retired sites and floors with the source of truth.

3. Verify AP placement after floor-plan changes, AP replacements, or map reimports.

4. Reprocess or update maps when the production floor layout changes.

5. Validate user-facing outcomes that depend on maps and AP placement after the update is complete.

Alert and Incident Maintenance

1. Maintain baseline telemetry rates for each major site or connector.

2. Review alert thresholds after large AP, controller, or service changes.

3. Keep the incident runbook owner and escalation list current.

4. Link repeated incidents to corrective actions rather than treating them as isolated events.

TROUBLESHOOTING WORKFLOW

Use this workflow before jumping into component-specific troubleshooting:

1. Identify the affected outcome. Examples: missing location data, connector offline, maps stale, IoT service degraded, Local Firehose not delivering events, or API consumer not receiving data.

2. Identify the scope. Determine whether the issue affects one floor, one building, one site, one connector, one controller, one integration, or the whole tenant.

3. Check recent changes. Review controller, firewall, DNS, SSO, connector, integration, map, and API-key changes.

4. Check Cisco Spaces dashboards. Confirm the affected component status and any related alerts.

5. Check connector health. Validate control/data channels, service status, resource usage, and logs.

6. Validate the upstream source. Confirm controllers, Catalyst Center, Meraki, or Webex are healthy and reachable.

7. Validate the downstream consumer. Confirm the application, receiver, or monitoring tool can authenticate and receive data.

8. Capture evidence. Record timestamps, affected scope, screenshots, logs, monitoring output, and recent changes.

9. Escalate with diagnostics if the issue persists or has business impact.

COMMON TROUBLESHOOTING SCENARIOS

Connector Is Offline or Degraded

Symptoms:

• Connector status shows offline, disconnected, or degraded.

• Control channel or data channel is not connected.

• External monitoring cannot poll the connector monitoring endpoint.

• Multiple dependent services stop receiving data.

Checks:

1. Confirm the connector VM or host is powered on and reachable.

2. Confirm DNS, default gateway, proxy, firewall, and certificate inspection changes.

3. In Cisco Spaces, open the connector detail view and review control-channel and data-channel status.

4. In the connector UI, review service status, CPU, memory, disk, and logs.

5. Confirm the connector can reach the Cisco Spaces cloud endpoints required by the deployment.

6. Confirm upstream controllers are still reachable from the connector.

7. Download diagnostics if the issue is not immediately resolved.

Resolution:

1. Restore network reachability or host resources.

2. Restart only the affected connector service when instructed by product documentation or support.

3. If the connector remains degraded, open a support case with diagnostics and recent change details.

Connector Resource Usage Is High

Symptoms:

• CPU, memory, or disk usage is persistently above baseline.

• Location update rate or data rate is much higher than normal.

• Connector services become slow or unstable.

Checks:

1. Compare the current controller, AP, client, IoT, and Firehose volume with the sizing assumptions used at deployment.

2. Check whether a recent site, controller, AP, or service expansion changed the connector workload.

3. Review connector service metrics for the service driving the increase.

4. Review disk usage and diagnostic/log retention.

Resolution:

1. Reduce unexpected traffic sources if the spike is caused by a misconfiguration.

2. Increase connector resources or redistribute workload if production volume has grown.

3. Tune external alert thresholds after the new normal is confirmed.

Wireless Controller Telemetry Is Missing

Symptoms:

• A controller is absent, inactive, or degraded.

• A site or floor stops receiving location updates.

• APs tied to a controller do not appear as expected.

Checks:

1. Confirm the controller is online and healthy in the wireless management system.

2. Confirm the connector can reach the controller.

3. Confirm required controller settings, credentials, certificates, and telemetry protocols remain configured.

4. Check for controller upgrades, certificate changes, firewall changes, or management IP changes.

5. Compare affected sites/floors with the controllers that serve them.

Resolution:

1. Restore controller reachability and credentials.

2. Revalidate connector-to-controller connectivity.

3. Confirm telemetry resumes and the affected location hierarchy updates.

Catalyst Center Sync Is Stale or Incomplete

Symptoms:

• Expected sites, floors, devices, or maps from Catalyst Center do not appear in Cisco Spaces.

• Integration sync fails or does not reflect recent source changes.

Checks:

1. Confirm Catalyst Center is reachable and healthy.

2. Confirm integration credentials and permissions are valid.

3. Review whether the source hierarchy, devices, or maps changed recently.

4. Check whether the expected site or device is in a supported scope for the integration.

Resolution:

1. Correct credentials, reachability, or permissions.

2. Re-run or wait for the next supported sync cycle.

3. Validate the location hierarchy, floors, maps, and AP placement after sync completes.

Meraki Data or Maps Are Missing

Symptoms:

• Expected Meraki networks, maps, floors, or APs do not appear.

• Map or AP metadata is stale.

• Meraki telemetry is absent for a site.

Checks:

1. Confirm the Meraki integration is authorized and healthy.

2. Confirm the expected organization and networks are in scope.

3. Confirm required network tags and map metadata are still present.

4. Confirm APs are online in Meraki and assigned to the expected network and floor.

Resolution:

1. Correct integration authorization, network scope, or tags.

2. Correct source map or AP metadata.

3. Validate the affected floors in Cisco Spaces after sync.

Webex Device or Workspace Data Is Missing

Symptoms:

• Expected Webex devices, rooms, or workspaces are missing.

• Room occupancy or environmental data is not available where expected.

Checks:

1. Confirm the Webex integration is authorized.

2. Confirm affected devices are assigned to the expected workspaces.

3. Confirm the devices are online and reporting in Webex.

4. Confirm the Cisco Spaces location hierarchy maps the devices to the expected site, building, or floor.

Resolution:

1. Correct Webex authorization or device assignment.

2. Revalidate the integration.

3. Confirm the affected data appears in the expected Cisco Spaces outcome.

Digital Maps Are Stale or Incorrect

Symptoms:

• Floor maps do not match the physical layout.

• AP markers are missing, duplicated, or misplaced.

• Location outcomes are inaccurate after floor changes.

Checks:

1. Confirm whether a facilities or wireless change occurred.

2. Review the floor map and AP marker placement.

3. Confirm the correct floor is associated with the site and building.

4. Confirm AP names and identifiers match the wireless source of truth.

Resolution:

1. Update or reimport the map.

2. Correct AP placement and floor association.

3. Validate location-dependent outcomes after the map update.

IoT Services Are Degraded

Symptoms:

• IoT Services dashboard shows degraded status.

• AP gateway, BLE gateway, or service activation status is unhealthy.

• IoT devices are not discovered or updated as expected.

Checks:

1. Review the IoT Services detailed status pages.

2. Identify whether the issue affects one WLC, one AP group, one floor, or all IoT Services.

3. Confirm the affected WLCs and APs are online.

4. Confirm connector service status and resource usage.

5. Check whether AP or controller upgrades, policy changes, or network changes occurred.

Resolution:

1. Restore WLC/AP health and connector reachability.

2. Correct gateway or service activation issues.

3. Validate device discovery or updates after recovery.

Local Firehose Events Are Not Delivered

Symptoms:

• Downstream receiver does not receive expected events.

• Local Firehose service metrics show no events or abnormal rates.

• The receiver reports authentication or connectivity errors.

Checks:

1. Confirm Local Firehose is enabled and healthy on the connector.

2. Confirm the downstream receiver is reachable from the connector.

3. Confirm the Local Firehose API key is valid and used by the expected consumer.

4. Review Local Firehose service metrics for event rate, failures, or sustained gaps.

5. Check firewall, DNS, certificate, and receiver changes.

Resolution:

1. Restore receiver reachability or authentication.

2. Rotate the API key if it is expired, exposed, or no longer trusted.

3. Validate event delivery with a known test window.

API Consumer Fails After Key Rotation

Symptoms:

• A downstream application returns authorization errors.

• Data flow stops immediately after a key change.

Checks:

1. Confirm which API key was rotated and which consumers were expected to update.

2. Confirm the consumer is using the new key and the correct endpoint.

3. Confirm the old key was disabled only after consumers moved to the new key.

4. Check consumer logs for authentication, rate-limit, or endpoint errors.

Resolution:

1. Update the consumer secret and redeploy or restart the consumer as required.

2. Validate data flow.

3. Disable the old key after all consumers are confirmed healthy.

Cisco Spaces Support Case Is Needed

Open a case when:

• A production connector remains offline or degraded after local triage.

• A Cisco Spaces outcome has sustained business impact.

• The issue appears to be a Cisco Spaces cloud, connector, or product defect.

• Support-directed service restart, log review, or recovery action is required.

Collect:

• Tenant name and account details

• Affected site, building, floor, connector, controller, APs, integration, and outcome

• Start time, time zone, and whether the issue is ongoing

• Business impact and urgency

• Recent changes

• Screenshots of status pages

• Connector diagnostics and logs

• External monitoring output, if available

• Steps already taken

Use the Cisco Spaces support entry point in the dashboard or Cisco.com support workflow. Set the severity based on business impact and Cisco support severity guidance.

VALIDATION AFTER RECOVERY

After resolving an incident, validate the full data path:

1. Confirm the affected component status is healthy in Cisco Spaces.

2. Confirm connector resource usage returned to baseline.

3. Confirm upstream controllers, networks, APs, maps, or integrations are healthy.

4. Confirm downstream applications or APIs receive expected data.

5. Confirm the affected business outcome has recovered.

6. Update the incident record with root cause, recovery steps, and preventive actions.

DOCUMENTATION AND CHANGE CONTROL

Maintain these records for each Cisco Spaces OS environment:

• Tenant and subscription ownership

• Admin owners and backup owners

• Connector inventory and service ownership

• Controller, Catalyst Center, Meraki, and Webex integration ownership

• Location hierarchy and map source of truth

• API key inventory, owner, consumer, and rotation date

• Monitoring thresholds and alert recipients

• Support contacts and escalation process

• Known limitations, accepted risks, and recurring corrective actions

FAQ’S

How often should connector health be checked?

Check connector status daily in Cisco Spaces. Use external monitoring for production environments where connector or data-path degradation must create an operational alert.

What is the best first signal for connector health?

Start with connector online status, control-channel status, data-channel status, and connector resource health. If external monitoring is available, add the connector monitoring API.

Should every site use the same monitoring thresholds?

No. Establish a local baseline for each major site or connector. Large sites, sites with IoT Services, and sites using Local Firehose may have different normal data-rate and resource patterns.

What should be checked after a wireless controller upgrade?

Confirm controller health, connector reachability, control/data-channel status, location update rate, affected floor data, and any services that depend on controller telemetry.

What should be checked after a map update?

Confirm the correct floor map appears, AP markers are placed correctly, the location hierarchy is accurate, and dependent outcomes still show expected data.

What should be done before rotating an API key?

Identify all consumers, stage the new key, update consumers during a change window, validate data flow, and then disable the old key.

SUPPLEMENTARY INFORMATION

• Cisco Spaces OS Runbook

• Cisco Spaces Day 2 Runbooks

• Cisco Spaces Connector Troubleshooting

• IoT Services Deployment, Monitoring, and Troubleshooting

• Cisco Spaces Support Update

• Cisco Spaces Developer Documentation