Keep sensor services operational during a platform outage

At 14:10, measurements stop moving. The team cannot tell whether the dashboard, one network or the entire data path has failed. Tree care can tolerate that uncertainty for several hours. A duty team relying on water levels may need to act at once.

A municipality keeps important sensor services operational by prioritising the municipal task first, setting a tolerable interruption for that task and preparing a reduced service mode. It needs reachable owners, independent contact and asset records, a staged recovery order and regular exercises. A backup alone does not sustain a service. Staff must know when to switch modes, which decisions remain authorised and how to handle later gaps in the data.

The municipal task determines the outage class

A sensor service includes more than a sensor, connectivity and a dashboard. It supports a task: public works plans a route, a duty officer assesses a water level, or a building team investigates a consumption spike. That task belongs in the first column of continuity planning. The platform and its components follow. Germany's BSI Standard 200-4 on business continuity management aligns planning with time-critical processes, resources and dependencies. The older but still practical NIST contingency planning guide follows a similar method: assess information systems and operations so requirements and recovery priorities are explicit.

Each municipal task needs four entries:

1. Maximum tolerable period of disruption: When would interruption cause unacceptable harm to safety, supply, legal duties or operations?
2. Recovery time objective (RTO): By when must the service deliver an agreed level again? The target must fall before the maximum tolerable period ends.
3. Recovery point objective (RPO): How much measurement history may be missing between the last reliable point and recovery?
4. Minimum service level: Which reduced capability is temporarily sufficient, such as a telephone status check, a fixed inspection route or read-only access?

Decision rule: A municipality should design degraded operation around the maximum tolerable disruption of the municipal task. RTO and RPO are derived targets for technology and data, rather than arbitrary supplier promises.

A soil-moisture service might be unavailable for a day if public works holds a conservative watering list. During a rapidly rising water event, one hour may already exceed the acceptable limit. The accountable service owner makes the classification with IT, information security and, where relevant, emergency management. The platform supplier can explain consequences but should not set the municipality's risk tolerance alone.

Map dependencies as one complete chain

For each priority task, the team draws one complete data path: sensor, power, radio or mobile network, gateway or network operator, ingestion, identity service, platform, automation, notification, end device and responsible staff. Suppliers, contracts and out-of-hours contacts belong on the same map. The GOV.UK guidance on digital service availability explicitly recommends understanding dependencies and their own availability expectations.

The crucial check is which links can fail together. A contact list inside the unavailable portal, a backup controlled by the production identity service, or an alert sent through the same cloud service provides weak protection. The UK's National Cyber Security Centre advises keeping critical SaaS data in at least one resilient backup with a separate blast radius, such as different identity sources for the application and the backup.

The dependency map does not need to become a specialist architecture diagram. One sheet per task is enough if every link names an owner, a sign of failure and an alternative. Each blank field becomes a specific action.

Degraded operation must define authorised decisions

A useful degraded mode is a smaller service promise. GOV.UK gives examples such as minimum functions, read-only access and queuing data until a third party returns. Municipal teams can apply the same principle to field work.

For a bin-fill route, degraded operation could mean that dispatch uses the latest exported priority list, adds known hotspots and records deviations on a prepared form. Water-level observation might switch to a fixed visual inspection interval where access and staffing are safe. Tree care could use a conservative standard route. Every variant needs a time limit and a named person who decides whether to continue or stop it.

The duty team's offline pack contains only what it needs: task class, activation threshold, roles and telephone numbers, latest approved asset list, manual procedure, authorised decisions, reporting route and criteria for returning to normal. It stays in a controlled location independent of the live system. Personal data and sensitive infrastructure details belong there only when access and protection remain governed during the outage.

Definition: Degraded operation is a pre-approved mode with reduced functions, named roles, a limited duration and recorded decisions. An improvised spreadsheet without approval, provenance or a return path does not meet that definition.

Recovery follows service priority

Technical teams may want to restore everything at once. Municipal operations benefit from a controlled order. The GDS disaster-recovery guidance separates activation, data protection, manual or automatic recovery and regular testing. It also describes the trade-off: very short recovery times demand more automation, redundancy and cost.

A municipal sequence can be:

1. Confirm the disruption, establish its scope and name the lead.
2. Activate degraded operation for the highest outage class and inform affected teams.
3. Verify identity, configuration and ingestion in a safe environment.
4. Restore the data path for the highest-priority task, then proceed by class.
5. Re-enable automations in a paused or supervised state.
6. Mark data gaps, check delayed measurements for duplicates and add missing decision records.
7. Return to normal only after the service owner and technical lead confirm the minimum criteria.

A visible dashboard does not prove complete data or working alerts. The release test therefore includes a known test sensor, an end-to-end notification check and a plausibility review by the municipal service owner.

Contracts should make continuity measurable

An availability percentage is too thin. Service credits do not replace a municipal service that was unavailable, as GOV.UK also notes in its supplier guidance. For critical external services, buyers should specify emergency contacts, notification and escalation thresholds, RTO, RPO, minimum degraded service, out-of-hours coverage, audit and reporting duties, and the form and frequency of joint exercises. The BSI proposals for business continuity strategies name these elements for supplier outages and recommend an exit strategy for critical external services.

Evidence matters more than wording. The supplier should be able to show when a restore last succeeded, who decides at night, how the municipality receives status information and how a failed exercise is repeated. The municipality records which parts remain its responsibility.

Three exercises expose different gaps

A 90-minute tabletop exercise tests roles, telephone numbers and decisions against a scenario. A technical restore test proves that configuration and data are accessible in a clean environment. An end-to-end exercise moves one selected municipal task into degraded operation and back under controlled conditions. The NCSC calls for regularly checked response plans; GDS recommends recurring restore and recovery tests.

The exercise lead records activation time, achieved minimum service, missing access, unclear decisions, the actual data gap and time to operational approval. The exercise closes only when each correction has an owner and a due date.

Where urbanOS fits this operating model

urbanOS, an Urban Data and Urban Intelligence platform for smart cities, is an especially strong fit for municipalities or large-estate operators that run several sensor types and networks in shared dashboards, supervise automations through run histories, and pass data into independent workflows through an API, GeoJSON or GPX. Those capabilities support dependency maps, approved data snapshots and controlled handling of automations. The platform does not replace a municipal continuity plan, independent backups, on-call staff, contractual RTOs or tested recovery. Buyer and supplier must agree and exercise those provisions separately.

The continuity card for each important task fits on one page: owner, outage class, maximum disruption, RTO, RPO, minimum service, activation threshold, offline records, dependencies, recovery order, release test and next exercise date. A team that can complete that card with the municipal service, IT and supplier has a credible starting point. Open fields at least identify the next concrete job before an outage.