What Happens to a Smart Streetlight When the Network Goes Down?

A smart streetlight network outage does not have one universal outcome. A luminaire may continue a documented local behavior, enter a configured fallback state, or need intervention, depending on its controller, driver, stored configuration, power condition, and system design.

That distinction matters because a communications outage is not automatically a power outage. The light may still have utility power while operators lose remote visibility or the ability to send commands. Conversely, a power outage can take the luminaire and its controller offline even when the central platform and communications network are available.

Key takeaways

• Treat network loss, power loss, and a device fault as separate operating conditions.
• A local schedule or fallback state is a configuration and equipment question, not a universal smart-streetlight feature.
• Remote monitoring, alarms, reporting, and commands may be unavailable or incomplete during a communications outage.
• Put the expected offline behavior and recovery test in procurement and acceptance requirements.

Start by separating the outage types

“The network is down” can describe several failures in a streetlight control system outage. If the conditions are not separated, an agency may assume it understands a lighting condition when it only understands part of the system.

A communications outage is a loss of the path between a field device and the system that manages or monitors it. The cause might sit in the field network, backhaul, carrier service, gateway, or another communications component. A central-platform outage affects the service used to view assets, receive alarms, or issue commands. A power outage affects energy at the luminaire, controller, or supporting network equipment. A device fault is a problem with a specific luminaire, driver, controller, or associated component.

These conditions can occur independently or together. The useful question is not simply, “Will the light stay on?” It is, “What is the documented behavior of this deployed system under this specific failure condition?”

For connected roadway lighting, that answer should cover the light state, schedule behavior, local control, remote visibility, alarms, event history, command handling, and recovery. It should also identify what the agency needs to verify on site rather than infer from a product category or a central-management dashboard.

This table is an evaluation framework, not a specification for any product or system. Each row requires confirmation against the deployed equipment, configuration, and agency requirements.

Why the power-versus-network distinction changes operations

When a luminaire retains power but loses communications, an operator may not be able to confirm its current state from a central interface. A remote command may not reach the device, and an alarm or status update may not arrive while the path is unavailable. That does not, by itself, establish whether the light will remain on, dim, follow a schedule, or change state. Those outcomes depend on the installed equipment and configuration.

When utility power is unavailable, local logic cannot make a disconnected luminaire emit light. Planning for communications continuity therefore does not replace power-resilience planning, field maintenance procedures, or applicable agency operating requirements.

What may continue locally, and what may not

Connected-lighting architectures commonly distinguish field equipment from a central management platform. The field side can include a luminaire, driver, controller, local settings, and a communications interface. The central side can include asset records, reports, alarms, schedules, and remote-control functions.

That architecture is useful, but it does not establish a particular offline behavior. A system may be designed with a locally retained schedule, a fallback state, or another defined response. It may also depend on a central service for some functions. The responsible approach is to request the current documentation for the exact controller, driver, platform, firmware, and deployment configuration, then test the stated behavior.

The LEOLink intelligent lighting system is presented by LEOTEK as a connected-lighting system with controllers and central management. Its public page describes remote switching, dimming, scheduled dimming, fault notification, reporting, maps, alarms, and asset management. Those descriptions help explain why communications availability matters to operations. They do not document what a LEOLink device does during a communications, cloud-service, or power outage, so this article does not assume an offline state for that or any other system.

Questions to ask about the controller and driver

The following questions can make a fail-safe lighting control discussion specific enough for a submittal review or acceptance test:

1. Which settings remain at the field device? Ask where schedules, light-level settings, and fallback instructions are stored, and how the supplier documents that storage.
2. What event triggers the fallback behavior? Clarify whether the relevant event is a lost network session, missed check-in, loss of the central platform, controller restart, or another condition.
3. What is the defined light state? Require the exact documented state or local schedule, not a general assurance that the system is “fail-safe.”
4. How is time maintained? Ask what time source the device uses, whether clock drift or holdover behavior is documented, how it behaves after restart, and what the documentation says about operation without its normal communications path.
5. What happens to missed commands? Determine whether commands are discarded, queued, retried, superseded, or handled in another documented way.
6. What is retained after recovery? Ask how configuration, device status, and event history are compared or reconciled after the connection returns.

These are evaluation questions, not assertions that every controller has local storage, scheduling, event buffering, or a particular holdover capability. The response should be tied to the exact equipment and current technical documentation.

Questions to ask about communications and central management

The communications path also needs a defined boundary. Agencies can ask which components are required for remote visibility, alarm delivery, reporting, and command delivery; what the operator sees when a device is unreachable; and how the system distinguishes a device issue from a communications-path issue.

Ask the supplier or integrator to map the relevant dependencies without assuming a preferred network architecture. That map can identify the field controller, communications service, gateway or backhaul where applicable, central platform, operator interface, and the handoffs between them. It can also identify component ownership, escalation contacts, and who confirms restoration.

Define a fail-safe lighting control policy before deployment

For a city or transportation agency, a fail-safe policy is an operating decision that should be made before a disruption. It should identify the intended response to a defined loss of communications and the evidence needed to confirm that response. The policy should be developed with the agency stakeholders responsible for roadway lighting, controls, operations, maintenance, cybersecurity, and applicable local requirements.

This is consistent with the broader operational-technology context. The National Institute of Standards and Technology's Guide to Operational Technology Security describes operational technology as systems that interact with or manage the physical environment and notes their performance, reliability, and safety requirements. It includes transportation systems among its examples. That guidance supports risk-aware planning; it does not prescribe a streetlight fallback level, local schedule, or network design.

Make the fallback state explicit

A policy should use precise language. “Keep lights operating” leaves too much open to interpretation. Instead, document the condition that triggers the response, the intended local behavior, the duration or review point, the manual-intervention process, the escalation path, and the restoration condition.

The intended behavior might be a locally stored schedule, a specified output state, a manual field procedure, or another approach supported by the deployed equipment. Agencies should avoid treating any one option as universally appropriate. Roadway operating needs, lighting design, maintenance procedures, local requirements, and the actual system architecture all affect the decision.

The policy should also say what is not available during the event. For example, if a communications outage prevents central confirmation of device status, operators need a documented method for determining scope and prioritizing field verification. This is an operations question, not evidence that the lighting system has failed.

Test the scenario before acceptance

An outage response is more useful when it is tested rather than assumed. A project-specific acceptance test can begin with a documented baseline: the representative assets, their expected state, the approved configuration, normal communications status, and the party observing the test.

Next, simulate the defined communications-loss condition using a method approved for the project. Observe the documented local behavior at representative devices and the central platform's visible status. Record which alarms, events, commands, or reports are available, delayed, or absent. Do not extrapolate a result from one device to an entire system without a documented test plan.

After restoration, compare the returned device status, configuration, time information, alarms, and event records against the baseline. Document exceptions, the cause if known, and the required corrective action. The agency's engineering and operations requirements should govern the test method and acceptance criteria.

Recover operations after connectivity returns

Restoring communications is only the beginning of recovery. Operators need to know whether the central view matches field conditions and whether the system shows events or changes that were not visible during the outage.

Streetlight network recovery procedures should state how the team confirms the scope, compares returned information with field conditions, and records exceptions. They should also identify who owns escalation and closure for each affected dependency.

Start by confirming the scope of the restored path. The recovery record can identify the affected assets or areas, the start and end of the known outage window, the communications component involved, and the personnel or organizations that confirmed restoration. Avoid assigning a root cause before the responsible parties have evidence.

Then reconcile state. Compare expected configuration with returned configuration, review the status of representative devices, and determine whether outstanding alarms, commands, or reports require action. If the system records event history, review it using the supplier's documented interpretation and retention behavior. If it does not, the agency should not assume a complete record exists.

Finally, close the operational loop. Update the incident record, identify any unresolved field verification, and decide whether the event changes the continuity policy, acceptance test, maintenance process, or procurement language. This gives operators a repeatable recovery procedure without claiming a universal restoration time or automatic correction capability.

Put continuity requirements in procurement documents

Procurement language can turn a broad resilience goal into verifiable requirements. Rather than asking whether a system is “reliable,” ask a supplier to state and document the behavior for a defined loss of communications.

An RFP, submittal checklist, or acceptance plan can request:

• the exact equipment, software, and configuration covered by the response;
• the documented offline behavior for communications loss, central-platform loss, restart, and power loss as separate conditions;
• the location and persistence of applicable schedules or settings;
• the dependencies required for monitoring, alarms, reporting, and remote commands;
• the operator indication of an unreachable device or communications-path problem;
• the documented handling of delayed, missed, or restored communications;
• the test method, representative sample, observations, and acceptance criteria;
• the post-recovery reconciliation process and responsible roles;
• software, firmware, and configuration change-control documentation; and
• current technical-document titles, revisions, and model applicability.

This approach helps keep a supplier response measurable without imposing a universal engineering answer. It also helps procurement teams distinguish a system capability described in marketing from a behavior documented for the proposed configuration.

For model-specific specifications, guides, warranties, and related materials, use LEOTEK technical documents and verify the current revision, model, and project applicability. A resource hub is a starting point for document validation, not proof of a particular controller's offline behavior.

Evaluate connected-lighting tools in context

Centralized tools can support routine connected-lighting operations by bringing remote control, schedules, status information, fault workflows, reporting, and asset records into an operator's workflow. The value of those functions during normal operation does not remove the need to define what happens when a dependency is unavailable.

Keep four layers distinct during evaluation: the luminaire and driver, the controller and local configuration, the communications path, and the central platform. A change in one layer does not automatically describe the condition of another. This framing makes it easier to ask evidence-based questions and prevents a project team from assuming that a cloud-visible asset has a documented local fallback state.

For an agency with a defined roadway-lighting continuity question, contact LEOTEK is a possible next step after the team has identified its equipment, operating scenario, and documentation needs. The conversation should validate project-specific requirements; it should not be treated as a promise of availability, response time, or fit.

Frequently asked questions

Do smart streetlights stay on if the network goes down?

It depends on the installed hardware, configuration, local settings, and power condition. A network outage alone does not prove that a luminaire will turn off, remain on, dim, or follow a schedule. Verify the documented response for the deployed system.

Is a network outage the same as a power outage?

No. A communications loss can limit remote visibility and control while a luminaire still has power. A power loss is a separate condition that can prevent the luminaire and controller from operating.

What should an agency test?

Test the specific communications-loss condition defined for the project, the documented local behavior at representative devices, the central platform's visible status, alarm and command handling, restoration, and post-recovery reconciliation. Use agency-approved acceptance criteria.

Can a cloud platform guarantee lighting during an outage?

Do not assume that it can. Require current, configuration-specific documentation and a project-appropriate test. A central platform's normal remote-management functions do not by themselves establish offline lighting behavior.

Treat communications resilience as a defined requirement

The practical response to a smart streetlight network outage is to replace assumptions with documented behavior. Separate the failure conditions, define the intended local response, identify what operators can and cannot see, and test recovery before the system is accepted.

That process supports a clearer decision for city and transportation-agency teams: not whether connected lighting is simply “on” or “off,” but whether the deployed system's offline streetlight operation matches the agency's documented operating needs.

References

• National Institute of Standards and Technology, Guide to Operational Technology Security.
• LEOTEK, LEOLink Solutions.
• LEOTEK, Resources and Documents.