How to Build Streetlight Performance Reports with Real Data

A streetlight performance report built from actual operational data looks fundamentally different from one assembled by asking supervisors to estimate metrics for their districts and averaging the answers.

Public works departments are regularly asked to demonstrate program performance — to council, to utility partners, to grant reviewers, to insurance carriers — and the standard response is a report assembled from whatever data is available in whatever format each district supervisor maintains. That produces a report that's more accurately described as a collection of estimates than a performance measurement. When the actual data — work orders closed, outage durations, maintenance costs per fixture — lives in disconnected systems and spreadsheets, assembling it into a coherent performance picture is itself a significant effort that produces a result no one fully trusts.

Atlas gives you streetlight performance data as a byproduct of normal operations — every work order created, dispatched, completed, and closed builds the database that performance reports draw from.

Here's how to build reports from it.

Why Operational Data Is the Foundation of Credible Performance Reporting

Performance claims that can't be traced to source data aren't performance claims — they're assertions.

Performance reports built from operational data create program accountability — and accountability creates the conditions for program improvement.

Step 1: Define the Metrics Your Program Will Track

Before assembling any report, decide what success looks like:

Outage rate — number of unique fixture outage events per month per 1,000 fixtures — the primary indicator of infrastructure reliability and program effectiveness
Mean time to repair (MTTR) — average time from outage report receipt to confirmed repair completion, calculated separately by priority category (emergency, urgent, routine)
Preventive maintenance compliance — percentage of scheduled preventive maintenance tasks completed within the scheduled interval, by district and schedule type
Work order backlog — total open work orders at end of period, by priority category and by district — a growing backlog indicates demand is outpacing program capacity
Repeat repair rate — percentage of fixtures generating two or more work orders within a 12-month period — a high repeat repair rate indicates deferred component replacement that should shift to a replacement decision
Cost per fixture per year — total maintenance program cost divided by active fixture count — the primary lifecycle cost metric for budget justification and program comparison

Define each metric formula precisely — what counts as an "outage event," what time baseline MTTR is calculated from — before collecting data, so the metric is consistent across reporting periods and comparable between districts.

Step 2: Verify Your Data Collection Is Complete Enough to Report

A metric is only as good as the data behind it:

Audit work order completion rates — are field crews closing work orders in the field when repairs are complete, or are some closed in batch at end of week with imprecise timestamps? MTTR calculated from imprecise timestamps is not a reliable performance metric
Verify fixture status updates at work order close — does the fixture status change to "Functioning" when the work order is closed, or is there a lag that makes the outage map inaccurate? Status update completeness affects outage duration calculations
Check inspection record completeness — are all scheduled preventive maintenance events recorded as work orders and closed when complete, or are some inspections completed without a work order record that would allow compliance calculation?
Validate district assignment accuracy — are all fixtures correctly assigned to districts? A fixture in the wrong district produces inaccurate district-level metrics even when the work order data itself is correct
Confirm date range consistency — are reporting periods defined consistently (calendar month, fiscal quarter, rolling 30 days), and are all users pulling reports with the same date range definition?

Data quality gaps found before a report is published are far less damaging than gaps discovered by a council member who asks where the numbers came from.

Step 3: Build Standard Report Templates for Each Audience

Different stakeholders need different views of the same data:

Field supervisor report — open work orders by priority in their district, overdue preventive maintenance, repeat-repair fixtures, and crew productivity metrics for the current period — operational detail without the portfolio-level summary
Management report — all-districts summary of outage rate, MTTR by priority, preventive maintenance compliance, and work order backlog with district-level breakdown — the full performance picture without individual work order detail
Council or board report — outage rate trend, MTTR trend, and a map showing geographic distribution of outage events — accessible to non-technical stakeholders without the operational metrics that are meaningful only to practitioners
Utility partner report — fixture count by ownership classification, outage events for utility-owned fixtures, response time for utility-coordinated repairs — the specific metrics relevant to the billing and maintenance agreement
Grant application report — infrastructure condition distribution, preventive maintenance compliance, replacement project pipeline — the program quality documentation that grant reviewers evaluate

Build each template once and populate it from the same underlying data — so each audience gets the right view without requiring separate data assembly for each report.

Step 4: Map Performance Data Geographically

Tabular performance metrics without geographic context miss the most important dimension:

Map outage events by location over the reporting period, showing geographic clusters where outage frequency is highest — clusters indicate infrastructure aging, utility reliability issues, or traffic incident frequency that demands attention before it appears in trend metrics
Color-code district performance on the map so the portfolio summary shows each district's performance on the key metric visually — a district in red is a different conversation than a district in green
Overlay condition data with outage location data to identify whether outage clusters correlate with poor-condition infrastructure — when they do, the capital case for replacement in that area is spatially documented

Also read: Plan LED Streetlight Retrofit

Step 5: Publish Reports on a Consistent Cadence

Performance reporting only improves performance when it happens regularly:

Monthly operational reports for field supervisors and department management, covering the current month's work order volume, MTTR, and backlog
Quarterly strategic reports for senior management and council, covering trend data across the quarter and year-to-date comparison to the same period in prior years
Annual program review covering the full-year metrics, condition trends, capital replacement progress, and program cost per fixture — the report that justifies next year's budget request
Event reports after significant incidents — major storms, vehicle strikes, infrastructure failures — showing the geographic extent of impact, response timeline, and restoration completion
On-demand reports for utility billing reconciliation, grant applications, and insurance claims that require documented performance evidence for specific periods

Consistent reporting cadence means management sees trends rather than point-in-time snapshots — and can make program adjustments before trends become crises.

Step 6: Use Reports to Drive Program Improvement

Reports that don't change behavior aren't worth producing:

Set performance targets at the beginning of each year — MTTR target, outage rate target, compliance target — and measure actual performance against targets monthly
Identify best-performing districts and investigate what's producing the outperformance — crew assignment stability, fixture age, maintenance schedule compliance, geographic density — so those practices can be applied in underperforming districts
Escalate persistent underperformance to management with a root cause analysis rather than just presenting the metric — a district with consistently poor MTTR needs a different response than a district with a temporarily high work order backlog from a storm event
Report on improvement over time by including prior-period comparisons in every management and council report — the direction of the trend matters as much as the current value

Use Cases

Building streetlight performance reports with real data matters for:

Municipal public works departments presenting annual program performance to council and city management who want more than anecdotal assessments of how the streetlight program is performing
Utility companies with service level agreements that require documented performance metrics for contract compliance, including MTTR by priority and outage response documentation
Maintenance contractors billing municipalities based on service volume and response performance who need performance documentation that substantiates the billing and the service quality claims in the contract renewal negotiation
Transportation departments managing federal-aid highway lighting programs that require documented inspection compliance and condition reporting for FHWA reporting requirements
Public works directors who are new to their positions and need a clear picture of their inherited program's performance before presenting to council or making maintenance budget requests

It matters for any organization where streetlight maintenance program performance is currently described in words rather than measured in data — and where data-driven accountability would improve both program quality and public trust.

Tips

Never average MTTR across priority categories — averaging emergency and routine response times produces a number that's meaningless for evaluating either — report each priority category separately
Show the denominator, not just the percentage — "90% compliance" means something different for 10 scheduled events than for 1,000; always show the count alongside the rate
Report work order type separately — mixing reactive outage repair work orders with preventive maintenance work orders in a single count hides the reactive/preventive mix ratio, which is itself a key program quality indicator
Include a data quality note when reporting metrics that you know have collection gaps — a MTTR metric based on 70% complete work order closure data is a different level of evidence than one based on 98% complete data, and the report should say so
Baseline before changing programs — if you're implementing preventive maintenance or upgrading your work order workflow, capture a full year of metrics before the change so you have a before/after comparison when evaluating the investment

Performance reporting built from real operational data in Atlas is how streetlight maintenance departments demonstrate program value, justify maintenance budgets, and create the accountability structure that drives continuous improvement.

Streetlight Performance Reporting with Atlas

Meaningful performance reporting requires operational data captured at the point of maintenance activity — not assembled from supervisor estimates after the fact. Atlas builds your performance dataset as a natural byproduct of work order creation, dispatch, and completion, so reporting is a query rather than a project.

From Estimates to Evidence

With Atlas you can:

Generate outage rate, MTTR, and preventive maintenance compliance metrics from actual work order timestamps and fixture status records — not from self-reported estimates
Build standard report templates for field supervisors, management, council, and utility partners that draw from the same underlying data with different levels of detail for each audience
Map performance data geographically to show which districts are outperforming and which need attention — giving management the spatial context that tabular metrics alone can't provide

Also read: Manage Streetlight Work Orders

Reports That Drive Program Improvement

Atlas lets you:

Track performance trends across reporting periods so management sees whether MTTR is improving or worsening, and can connect program changes to metric changes over time
Identify best-performing districts and underperforming districts on a map, enabling targeted program improvement rather than across-the-board interventions
Export performance data in any format for grant applications, state and federal reporting requirements, and utility billing reconciliation

That means performance conversations with leadership built on actual data — not best guesses — and a program that improves because performance is measured.

Performance Reporting at Any Scale

Whether you're managing a streetlight program with 400 fixtures in a small municipality or 60,000 in a large city, Atlas generates performance metrics from the same operational data without requiring a separate reporting or analytics platform.

It's streetlight performance reporting built into the platform where maintenance happens.

Build Your First Performance Report Today

Performance reporting starts with operational data — and operational data starts with a platform that captures it as a natural byproduct of maintenance work. Atlas gives you both, without a separate analytics tool.

In this article, we covered how to build streetlight performance reports with real data — from defining metrics and verifying data quality to building audience-specific report templates, mapping performance geographically, establishing reporting cadence, and using reports to drive improvement.

From monthly operational reports through annual program reviews and grant documentation, Atlas supports streetlight performance reporting without manual data assembly.

So whether you're building your first data-driven streetlight performance report or replacing a collection of supervisor estimates with actual metrics, Atlas gives you the reporting foundation your program needs.