Last week two of our scripts reported numbers that looked clean. One said an app had 0 reviews, three days running. The other said it had received 40 photos with 0 failures. Neither told the whole story. Both numbers meant the script couldn't read something, and neither one said so.
This follows my posts on failures hidden behind exit code 0 and on checks that borrowed from the code they checked. These zeros came from the readers.
At the end I'll ask which warning sign you trust most, because we ran into three in one week.
Zero reviews, three days running
One of our Android apps launched on October 28, and a script checked it six times over 72 hours: search rank, installs, rating and reviews. At 24 hours it wrote "reviews: 0". At 48 hours, the same. A separate morning check on the 31st agreed.
The app had a review, posted on launch day. We found it when someone opened the review page in the developer console.
The two readers failed in different ways. The rank script counted reviews from the "N reviews" label, and the store page only shows that label once an app has a public rating. With one review, the page still showed no rating, so there was no label, so 0. The morning check looked for review IDs that start with gp:. This review's ID was a UUID.
The part that stung: from the third reading on, we kept the raw HTML. The review is in the October 29 and October 30 files. It sat on disk for two days, and the rank script read both files as nothing.
The reader now finds reviews by shape instead of by label or ID format: a star value from 1 to 5, a body, a timestamp and an app version, inside the page's embedded data block. We also treat the console as the source for review and install counts. The public page is a second reading.
40 received, 0 failed
Another script collects the day's photos from a web list of notes, for our blog drafts. On October 29 it printed "received 40, failed 0" (translated). Forty photos came in, 20 from each of two notes. The third note's 22 photos were missing entirely, and so were 4 more from the second note: 26 photos, every one below row 40.
The list's first screen holds 40 rows, and the script read what was rendered and stopped there, so nothing failed and the failure count was honest, but the received count was just the screen size. The run the day before had also received exactly 40. We never checked whether anything was missing that day.
The fix calls scrollIntoView({block: 'end'}) on the last row and reads again while the list keeps growing. It stops when the last row's upload date is before that day, after 3 scrolls with no new rows, or after 20 scrolls. It counts rows as it goes, in case the list drops rows that scroll out of view. And it prints how many rows it read and why it stopped. The rerun that evening printed "first screen 40 rows → 80 rows, 2 scrolls, stopped at a row from the day before" (translated), then 26 new photos and 0 failures. I'd take that line over a clean 40 every time.
Two numbers that can't both be true
The same launch log had a third number worth doubting. The store page showed "0+" installs for all 72 hours. One review means at least one install, so "0+ installs" and "1 review" can't both describe the same app at the same time.
This time the parser was right. The page's data block and the visible label both said "0+". The public figure updates late. But the contradiction is what made us look, and looking took two places and a minute.
Three signs, in the order they'd have helped
- A count that equals a page size. 40 of 40 should have been a question, not a pass.
- A zero that lasts. Three readings of 0 in a row is a reason to check a second source once.
- Two numbers that contradict. A review without an install means one figure is stale or misread.
None of these needs a new tool. Each is a line in the output: how many rows the reader saw and why it stopped, which source a zero came from, and a flag when two figures disagree.
A question
When a script hands you a suspiciously clean number, what tips you off: a count that matches a page or batch size, a zero that has lasted too long, or two numbers that can't both be true? Which one has actually caught something for you?
Sources
- MDN, Element.scrollIntoView() (the
blockoption sets vertical alignment in the scrolling container): https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView, accessed 2026-11-02 - Everything else: our launch log, commit history and lessons log, October 28 to 31.
This post was drafted with AI help. The numbers and facts come from my own logs and repo.
Top comments (1)
Sometimes the script does say so, on stderr. My status line's context bar sat at 0% whenever the percentage had a decimal in it. Under a German locale, bash 3.2's builtin printf rejects 37.4 as an invalid number, so it wrote that error to stderr and the bar got 0. Claude Code shows the script's stdout, and all I ever saw there was a clean 0%. The fix was LC_NUMERIC=C plus rounding in jq, which doesn't depend on the locale.