Our blog said 7 minutes ofreading. It was 1.

We publish about auditing other people's websites. About numbers nobody checks, outdated information left live, text the AI generated and nobody reviewed.

So this part is only fair: we ran the audit on our own blog and the error was in all 30 posts. Every single one.

It isn't serious in the sense of causing losses. Nobody lost money. But it is exactly the kind of error we write about — a number typed by hand, which looked right, which nobody recalculated, and which stayed live for months saying something that wasn't true.

It is worth telling the whole story, with the numbers. Telling only half of it would be the same flaw all over again.

What was wrong

Every blog post has a reading-time field. It is that “7 min” that appears under the title, next to the date.

In the 11 posts of the Radar series, that field said 7 min.

The actual text of those posts had between 155 and 225 words.

At 200 words per minute — a conservative average for reading in Portuguese, and the same constant our code uses — 200 words take about 1 minute. Not 7.

The error wasn't a rounding issue. It was sevenfold.

And it wasn't only in the Radar. When we measured the 30 published posts, all 30 were off by 2 minutes or more. None got it right. The closest one was the longest post on the blog: it declared 12 minutes and measured 10.

They all erred in the same direction — upward. No post underestimated its own length.

Why the error slipped through

The explanation is boring, and that is exactly why it is worth recording: the number was typed by hand.

Whoever created the post estimated the reading time and wrote it down. At the time, the estimate was a reasonable guess — the writer had in mind the post they intended to make, not the one that ended up coming out. Later the text got shorter, or never reached the planned length, and the number stayed.

Notice what didn't happen: nobody lied, nobody was careless, nobody made a wrong decision. The field simply didn't belong to anyone. There was no step called “check the reading time,” so there was never a moment when someone would look at it again.

It is the same pattern we described in the post about AI without review: the problem isn't a lack of care, it is the absence of an owner. A number without an owner ages on its own.

The error had a second victim

This is where it stops being a metadata detail.

The blog has an on-screen timer: a ring around our brand's eye that empties as you scroll down the page, like the bar on a story. It exists to give you a sense of how much is left.

That ring reads the reading-time field. So, on a post that declared 7 minutes and had 45 seconds of text, the ring set itself to take seven minutes. Whoever finished reading reached the end of the page with the timer still near the start.

The component was right. Its math was right. The data it received was what was lying — and the result is that the most visible piece of the blog, built precisely to create a sense of rhythm, communicated the opposite of what was happening.

An error in a number rarely stays contained in the number. It leaks into everything that relies on it.

What we did

Three things, in order — and I didn't expect the second.

First, we measured. We wrote a script that opens each post, extracts only the text the reader actually reads — section titles, paragraphs, list items, highlight boxes, captions — and ignores image paths, variant names and code. Then it compares that with the declared number.

Then, we found out the script was wrong too. In its first version it counted the same paragraph twice, in cases where the code formatter had broken the line between the field name and the text. The total inflated by almost 100% — and only in the newest files, which were precisely the ones I was writing that day.

What saved us was an implausible number: a post I had just written, with roughly 1,100 words, showed up with 2,100. If the error had been 10%, it would have slipped right through.

Finally, we corrected with a threshold. Every post with a difference of 2 minutes or more was adjusted. The threshold exists because a 1,400-word text that says 8 minutes and measures 7 is rounding, not lying, and touching it would only muddy the history. None of the 30 was within it.

And three posts grew: the ones with a topic that could sustain an article went from ~200 to more than 1,000 words. Then the declared time became true again because the text changed — not because the number changed.

The script stayed in the repository. Now it can run before publishing.

Where this argument stops holding

Three honest caveats.

Reading time is an estimate, not a measurement. 200 words per minute is an average that describes nobody exactly: fast readers do it in half the time, someone on their phone on a bus takes twice as long. Precision was never the point. The point is not being off by sevenfold.

The tool that measures also makes mistakes. It did here, in the first version, and what saved us was a number absurd enough to draw attention. An audit doesn't eliminate errors — it trades an invisible error for one someone can see. That is better, and it isn't a guarantee.

And publishing this doesn't put us above anyone who didn't audit. We found one error. That means there is at least one category of error we know how to look for, not that the rest is clean. There are probably other numbers on the site nobody checked, and the only way to know is to keep looking.

An audit isn't a badge you earn. It is something you do again.

The reason for telling this with numbers, instead of in general terms, is simple: the vague version is useless. “We identified inconsistencies and improved our process” teaches nobody anything and costs nothing to say.

7 minutes declared, 1 minute real, 30 posts corrected, a bug in the measuring tool itself, a script in the repository — that can be verified.

If we write about auditing others, the least we can do is show ours in the open.