Ten Pages or Nineteen Hundred

For decades the San Juan County Sheriff's Department in Washington sent the local papers a weekly log, about ten pages long, and the San Juan Journal ran a trimmed version of it on page four. This summer the sheriff stopped sending it. The Journal filed a records request for the department's call logs from July 1 to July 27 and got back more than 1,900 pages.

Nobody lost any data in San Juan County. The department had every call: every alarm check, parking tow, welfare check and DUI. What went missing was the ten-page version, the one a person could actually read.

That gap turns up again and again in our work. Police departments are very good at collecting records and surprisingly bad at the last step, which is handing the public a plain list of what happened last week. A media log, a blotter, a CSV on an open data portal: these are the simplest public data products a department makes. Over the past few years we've watched them break in small counties, in a Florida city, and in the second-largest city in the country, for reasons that rhyme.

What the sheriff said

The San Juan case is the gentlest of the lot, because nothing technical failed. According to the Journal's August 3 update, Sheriff Eric Peter withdrew the Sheriff's Log because of a “significant increase in public records requests” for the incidents it listed and for the body-camera footage behind them. The department called the volume an “unsustainable burden” on its civil office and its one public records clerk.

Then came the paper's own records request. The county rejected the first one. A reporter at the San Juan Islander, who had already gotten the same records, passed along wording the county would accept. The second request worked, and the answer was the 1,900-page raw file. So the log was pulled to cut down on records requests, and its absence produced a records request. (The Journal says it will keep filing them for as long as the department declines to send the log.)

We aren't going to second-guess a one-clerk records office about its workload. We would point out that the ten-page log was the cheap version. Someone at the department had already done the editing: dropping the parking complaints, leaving out suicides, keeping the arrests and the domestic calls. The raw dump makes the newspaper redo that work, and the public now waits for a records cycle to see it.

A report template is software too

In Grant County, Washington, the failure was purely technical. At the start of 2025 the sheriff's office and the city police departments there (Moses Lake, Warden, Soap Lake) moved from Spillman, a records system they had used for years, to a newer product from 365 Labs. The Columbia Basin Herald reported on January 17, 2025 that one of the things the switch broke was exporting police logs. The paper said it would stop publishing police and jail logs until that was fixed.

The officials quoted were candid. A Moses Lake police captain said the new system had “a lot of great functionality, but also a lot of bugs.” The sheriff's spokesman said the hard part was getting jail records out of the database in a publishable format, on demand, and that nobody knew how long the adjustment would take.

This is what we think people miss about the media log. It looks like data, but it's really a saved report: a query, a set of columns, a filter for what not to show, maybe a formatting macro that a records clerk set up in 2011 and nobody has touched since. It lives inside the old system. When the department buys a new one, the incidents migrate. The report usually doesn't, because nobody wrote it into the contract.

Retired, not replaced

The cleanest example we have came to our own inbox. On the morning of October 6, 2026, a records technician at the Leesburg Police Department in Florida (Lake County, northwest of Orlando) emailed the department's media list: SpotCrime, several Orlando TV newsrooms, a news radio station and the regional Crimeline. The weekly Media Report “will no longer be provided,” the email said, because “the software utilized to compile this data has been retired by the City's IT department.”

We wrote back the next morning and asked the obvious question: what system had the department moved to, and did it offer any kind of report or blotter? The answer came seven minutes later. The department had not moved to new software for the Media Report, and “at this time we do not have a way to compile a list with our current system.” For questions about specific incidents, it said, contact the public information officer, or the records supervisor, or the city's online public records portal.

Read that twice, because it's a different failure from Grant County's. Nothing was migrated and nothing broke. A city IT department retired a tool, and the tool turned out to be the only thing that could make a list of the week's police incidents. The incidents are still being recorded. Leesburg just has no way, by its own account, to put them in a list. What the public gets instead is a records portal, which is to say a request, a queue and a wait, one incident at a time.

To be fair to the people on the other end of that email, a records technician doesn't choose the city's software, and the answer came fast and plainly. That's the point, really. Nobody in this story decided the public shouldn't have the log. It just stopped existing when a server did.

Three times longer, half as useful

Sometimes the export survives the move and gets worse. In December 2022, Brandi Makuski, editor of the Point/Plover Metro Wire in Wisconsin, explained to readers why the police blotter had gone strange. Early that year, the Portage County Sheriff's Office and the Stevens Point and Plover police departments had moved to new reporting software. After a few weeks with no blotters at all, the blotters came back about three times longer.

Longer is not better. The sheriff's blotter for December 19 ran 44 pages, compared with the eight or nine pages the press used to get each Monday. Many entries had no names, no ages, and no indication of what a citation was for. Makuski wrote that the press copy held “less than half of the information we need,” padded out with material useless to anyone outside the dispatch center.

That last phrase is the whole problem in miniature. A computer-aided dispatch system is built for dispatchers. Its default output is whatever a dispatcher needs on a screen: unit numbers, status codes, timestamps for every radio check. A blotter is a translation of that for outsiders, and the translation is the part that has to be built on purpose. (The Metro Wire's sidebar this month says Stevens Point blotters “may resume” soon. We read that as the story not quite being over, nearly four years on.)

The Los Angeles version

The largest example we know of is one we've covered many times, so here is the short version. On March 7, 2024, the Los Angeles Police Department replaced its legacy records system with Motorola's PremierOne. Its public crime feed on data.lacity.org, which had published block-level incidents since 2010, slowed down, then stopped. The legacy file is still online, and you can check where it ends yourself:

curl -s -G "https://data.lacity.org/resource/2nrs-mtv8.json" \
  --data-urlencode "\$select=max(date_occ), count(*)"

Run on October 18, 2026, it returns 1,004,894 rows and a last occurrence date of December 30, 2024. The portal now titles the dataset “Crime Data from 2020 to 2024.”

What followed was seventeen months of explanations, which we laid out in our post on the June 2026 block-level release. First it was resource constraints. Then the department was “still building the mechanism” to refresh the data. Then the data was “not user-ready.” Then it “continues to repair, sanitize, and review,” and only the mapping vendor could produce block-level addresses. Three organizations, SpotCrime among them, filed records requests in the meantime, and we eventually sued.

On June 9, 2026, one week after the city's primary election, LAPD published the block-level data on the open data portal, with hundred-block coordinates in fields named hndrdth_lat and hndrdth_lon. The department had produced them itself. The mechanism, apparently, had been buildable all along. And as we wrote in a follow-up, the restored feed still carries roughly half as many incidents per day as the old one did.

The export they already run

On October 16, the Marshall Project published a toolkit for reporters working with FBI crime data, written by data reporter Jill Castellano. Most of it is about how to read NIBRS without fooling yourself. One tip, tucked into a section on local police, goes straight to the problem in this post. When an agency doesn't make its crime data easy to get, Castellano writes, reporters have had luck asking for the same fields the agency already submits to NIBRS.

Sit with that for a second. According to the toolkit, about 90% of Americans now live in a jurisdiction that reports to NIBRS. Each of those agencies, directly or through a state repository, produces a structured, validated, fixed-format file of its incidents for the federal government: offenses in one segment, victims in another, arrestees in a third, all to a published specification. In many places, the same system that struggles to produce a weekly media log is already producing a federal extract.

The NIBRS file isn't a drop-in blotter, and the toolkit is clear about why. It carries no names, no incident addresses and no narratives, which are most of what a newspaper log is for. The FBI's monthly release, started in 2025, is still patchy, with many agencies sending partial months or none. But the toolkit's own list of questions for local police ends with the one we would put first: can you give me the data you send to NIBRS, more often than you send it to the FBI?

The toolkit also explains, in passing, why the logs keep breaking. Moving to NIBRS was a “time-consuming and expensive undertaking,” and some agencies replaced their database systems to do it. That is the Grant County story and the Los Angeles story in one sentence, and Leesburg shows you don't even need a migration. (The toolkit names LAPD and NYPD among the late arrivals.) The federal format got rebuilt because the FBI required it. The local one got rebuilt only if somebody remembered.

Our view is that this gives a records requester a cleaner test than any argument about burden. If an agency says it can't produce a list of last week's incidents, ask for its NIBRS submission. If it can produce that, the problem is the last mile, and the last mile is a report template. If it can't produce that either, it has a bigger problem than its press log, and the FBI should probably hear about it.

Why a spreadsheet turns out to be hard

We don't think most of this is bad faith. Los Angeles is the exception that gets the attention, and even there the record suggests a department that let a public output die and then struggled to admit how easy it was to restore. In the smaller cases, the pattern looks more like neglect than secrecy.

Here is how we'd describe it, as a company that ingests these feeds for a living. Departments buy records systems to run operations: dispatch, case management, evidence, court packets, state and federal reporting. Those requirements get written down, tested and paid for. The public export is almost never on that list. It was built once, years ago, by whoever happened to know SQL, and it gets discovered missing a week after go-live, when a reporter calls.

The redaction step is real work, and it's the honest reason a log can't just be a database dump. Victims' names, juveniles, sexual assault locations, suicides, sometimes officers' names. States keep changing those rules, too. But it's a rules problem, and rules problems are solved once, in code, and then run every day. The San Juan log already did it, by hand, every week, in ten pages. We wrote about the same idea in our post on privacy suppression: the suppression list should be published alongside the data, so everyone can see what was held back and why.

There is also a staffing piece we don't want to wave away. One records clerk serving a county is not a technology problem. But it is an argument for automating the log, not for withdrawing it. A log that publishes itself creates no records requests. One that stops publishing creates a lot of them, as the Journal showed.

What would fix it

None of this needs a new standard or a federal grant. It needs somebody to treat the public log as a product with an owner. If you work in or with an agency that's about to change systems, these are the things we'd ask for:

1. Put the public export in the contract.Name the fields, the refresh schedule and the format (CSV or an API, not PDF) as acceptance criteria, the same as state reporting. If the vendor won't sign up for it, you've learned something.
2. Run the old feed and the new feed side by side.Don't turn off the legacy export until the new one matches it on daily counts for at least a month. Phoenix's six blank days are what a hard cutover looks like from outside.
3. Write the redaction rules down and publish them.A suppression list that lives in a clerk's head walks out the door with the clerk.
4. Publish the boring version on a schedule. A daily file with date, time, hundred block, offense and disposition covers most of what reporters and residents want. It is also most of what keeps records requests down.
5. Announce the gap before it happens.A one-line notice (“the log will be unavailable from March 7 while we migrate”) costs nothing and saves every downstream user from guessing whether crime stopped.

If you're on the other side, building on these feeds, the advice is shorter. Check the latest record date on every source you ingest, every day, and alarm when it stops moving. That check is how a gap like Phoenix's shows up, usually before anyone announces it. A feed that goes quiet is far more often a software change than a safer city, and our post on NIBRS deletions covers the quieter ways rows disappear.

The Sheriff's Log was ten pages. To get it back, the San Juan Journal needed a rejected request, wording borrowed from another paper, and nineteen hundred pages of parking tows. It still ran on page four.