Government data

How Often Does FMCSA Data Update? A Broker’s Guide to the Different Clocks

By VerifyCarrier · · 4 min read

FMCSA data has several clocks: the event or effective date, government publication date, retrieval time and review time. A lookup performed today may describe an earlier state of the carrier. Check which date governs the decision before the next load.

Different FMCSA products have different schedules

FMCSA describes its Company Census File as a daily export from a database that is already 24 hours old. Its public crash and inspection files also have daily export schedules. Those descriptions do not promise that an event reported by a state will appear immediately. Reporting, processing, publication, and a downstream service’s import are separate stages.

The SAFER FAQ describes Company Snapshot information as updated daily, with inspection and crash counts updated weekly. SMS uses monthly snapshots. A daily raw inspection export and a weekly aggregate on a company snapshot can therefore disagree without either page being broken. Compare the same population, time window, and definition before treating a difference as an error.

Sources: FMCSA Open Data Program; FMCSA: SAFER frequently asked questions; CSA FAQs

Keep four dates in the review

The event or effective date tells you when something happened or is scheduled to take effect. The publication date tells you when the source made the observation available. The retrieval date tells you when your service obtained it. The review date tells you when a person considered it. Use those names explicitly rather than placing an unexplained “updated” label beside the record.

Consider an illustrative insurance cancellation with an effective date of October 8, a source publication date of October 1, and a retrieval date of October 2. The retrieval does not move the cancellation to October 2. Nor does the notice by itself establish what coverage will exist on October 8: a replacement or another relevant filing may need review. Preserve the dates and check the current official record and the appropriate insurance contact.

Sources: FMCSA: Insurance filing requirements

Why a daily job can deliver unchanged data

An automated process can successfully download the same file on successive days. A changed retrieval timestamp is not evidence that the underlying rows changed. Equally, an unchanged file is not necessarily a failure: the source may have had nothing new to publish. File checksums, row counts, source timestamps, and observed field differences help distinguish those cases.

For brokers, the practical distinction is between “we checked and found no new supported observation” and “we could not check.” For an integration, preserve an explicit unavailable or stale state. Returning the previous successful response with a fresh clock can make a technical failure look like current evidence. Ask a vendor whether its freshness label describes its request, its import, or the source publication.

Modernization changes more than the website

FMCSA’s current open-data documentation distinguishes modern MOTUS operating-authority datasets from archived legacy files. A familiar file name or an old parser is not enough to establish that a feed remains the current operational source. The agency documents changes to relationships between authorities and docket numbers and to how difference files represent removals.

That matters even if a broker never sees the raw files. A service can continue returning successful responses while interpreting new fields incorrectly or relying on an archive. When a record appears stuck, ask which dataset and schema produced it. Keep the original record identifiers so a reviewer can trace an answer back to the appropriate source.

Sources: FMCSA Open Data Program

What to do when records disagree before pickup

If the difference affects the planned operation, obtain the relevant current official record and route the unresolved issue through your brokerage’s approval process. Record the source consulted, the remaining uncertainty, the person responsible, and any condition that must be satisfied before the load proceeds. An outage should produce an explicit exception, not an undocumented assumption.

A review note someone else can use

A useful note says: “Reviewed source X at 14:20 UTC; source publication dated September 28; event effective October 3; replacement status still being confirmed; assigned to operations before tender.” It separates known facts from unfinished work and prevents the next shift from mistaking a saved result for a completed investigation.

Compare successive observations only when their meaning and coverage are compatible. If yesterday’s import failed, today’s change may have occurred anywhere within that gap. Describe it as newly observed, rather than inventing an exact event time. That small wording choice makes historical monitoring more accurate and the resulting decisions easier to explain.

Sources checked . Procedures are VerifyCarrier’s recommendations; examples are illustrative. How we prepare and correct these guides.