Contact

GlossaryPublic records, privacy, and data quality

Reporting lag

Reporting lag is the delay between a defined event and its recording, submission, or publication. The endpoints determine what the delay means.

Reporting lag is the time between an event or reporting period and a later stage when its information is recorded, submitted, or made available. The phrase is incomplete without its endpoints. A delay from occurrence to police report is different from a delay between an agency's submission and publication on a public dashboard.

In public-safety data, several clocks can run at once. An event occurs, someone reports it, the agency creates or updates a record, data are submitted to another system, and a public release is produced. A date attached to one stage should not silently stand in for another.

Why recent totals can change

A recent period may look quiet because some records have not reached the published dataset yet. Later additions can increase an earlier month's total without any new event occurring in that month. Corrections or reclassifications can also revise previously released figures.

The FBI's NIBRS User Manual documents procedures for updating previously submitted incident information. That establishes why a submission should not automatically be treated as a permanently frozen account. It does not tell a reader the publication delay for every local dashboard. FBI NIBRS User Manual, version 2025.0, reporting updates

For local files, the publisher's update schedule and date definitions are essential. San Francisco's calls-for-service explainer distinguishes multiple operational timestamps and describes the dataset's publication context. Its September 2021 revision is a historical source, so a current refresh schedule should be verified separately. San Francisco dataset explainer

Example

Hypothetical: A theft occurs on Monday, is reported to police on Wednesday, and appears in a public data release on Friday. The occurrence-to-report lag is two days. The report-to-publication delay is another two days. The full occurrence-to-publication interval is four days.

A chart grouped by occurrence date places the event on Monday. A chart grouped by report date places it on Wednesday. A download log showing Friday identifies when the public copy appeared. Those dates describe different stages of the same event.

Now suppose a monthly file is downloaded on the second day of the following month and again three weeks later. If the later download contains additional records for the earlier month, the difference may reflect reporting lag or corrections. It should not automatically be described as a new surge during the later download week.

Common confusion

Reporting lag is not response time. Response time concerns the operational interval for help to be assigned or arrive. Reporting lag concerns when information becomes recorded or available.

It is also different from an event's duration. A long-running incident can be entered promptly, while a short incident can be reported much later. Nor does an old event date prove the dataset is stale; the record may have been newly reported or revised.

A missing recent value is not a known zero. The reporting period may be incomplete, an agency may not have submitted, or the publication may not yet include the latest records. These possibilities require coverage information rather than guesswork.

Making fair comparisons

State the date field used to group events, the download date, and any completeness cutoff. Compare periods with similar opportunities for late reporting, or clearly label the newest period provisional.

Preserve earlier extracts when examining revisions. They allow a reader to distinguish what changed in the published record from what changed in underlying event activity. If a source provides no lag distribution or finalization rule, do not invent a universal waiting period after which the data are complete. Describe the known update process and the remaining uncertainty.

Sources