33 of our 38 pages say we check every 30 seconds, and three of them explain how to change a setting that does not exist

Notifio is a desktop app that watches rental search pages and tells you when a listing appears. The whole product is one promise about time: you hear about a room before the people who wait for the portal's own email. So the polling interval is not a detail of the implementation, it is the thing being sold, and it shows up all over the marketing site.

I wanted to know exactly how often we say it, and whether we say the same number every time. The app and the website are separate projects in separate workspaces, and the website has never imported a line of the app, so the only honest way to check is to read the rendered output.

The measurement

Fetch the sitemap, fetch every URL in it, strip <script>, <style> and <head>, strip the remaining tags, unescape the entities, and count.

curl -s https://notifio.app/sitemap.xml | grep -o '<loc>[^<]*</loc>' 

Thirty eight URLs, 36,947 words of visible text between them. Against that text:

The five pages that never mention it are /about, /download, /privacy, /terms and /help.

That last one is the problem. /help is the page whose job is to answer the question. It contains the answer. The answer is not in the visible text because it is inside a collapsed accordion whose panels are not in the DOM until you click, a rendering quirk I wrote about in three of our six FAQ answers disagree with the code and have still not fixed. Pull it out of the hydration payload and the FAQPage JSON-LD, where it sits twice, and it reads:

How often does Notifio check for new listings?
By default every 60 seconds per monitor. You can adjust the interval in the monitor settings.

Three claims in two sentences. One of them is a number that disagrees with 33 other pages. One of them is a unit that cannot be right. One of them is a settings screen.

What the code has

The interval is one constant, in one file, with no setter and no reader outside its own module:

// app/src/monitor.ts /** * How often each search should be checked. This is the interval between the * *starts* of two cycles, not an extra pause bolted onto the end of one. The * time already spent scraping counts towards it. */ const POLL_INTERVAL_MS = 30_000; 

So the number is 30, and the 33 pages are right.

The unit is where it gets interesting. A cycle walks the searches one after another, which is also why the app caps you at fifteen of them:

// app/src/limits.ts /** * Every search is scraped one after another inside a single poll cycle, so the * count directly sets how stale the slowest search gets. At ~3-5s per search, * 15 keeps a full cycle under a minute. */ export const MAX_SEARCHES = 15; 

"Every 60 seconds per monitor" is not a smaller version of the truth, it is the wrong shape. The interval belongs to the cycle, not to a search. Fifteen searches do not each get their own timer; they get a position in a queue that restarts every thirty seconds. I measured that cadence start to start for an earlier post, and the reason it is start to start rather than a sleep at the end is exactly this: the search at the back of the queue has already waited the longest, and making it wait another full interval is the opposite of the product.

And the settings screen:

$ grep -rn "interval" app/src/settings.ts app/src/types.ts \ app/src/form-schema.ts app/src/renderer/types.ts $ grep -rln "interval" app/src/renderer/ app/src/renderer/hooks/useNow.ts 

Nothing. The one file in the UI that contains the word is a twelve-line clock hook whose only job is to re-render relative timestamps, which I wrote about in three clocks in one window. A search in Notifio has a name, a URL and an enabled flag. It has never had an interval, in any released version.

Two more pages describe the same control

I expected the FAQ to be the only offender. It is not. Both of the other 60 seconds mentions are setup instructions on generated site pages, and both of them are written as advice about a dial:

/alerts/huurwoningen, step 3:

Paste into Notifio and set the interval. 30 seconds is the default and is right for a city search. For a quiet town, 60 seconds is plenty and produces less traffic.

/alerts/spotahome, step 3:

Add it as a monitor at the default interval. The catalogue is small enough that 30 or 60 seconds both work. There is no need to push it lower.

Read those as a buyer. The word "default" implies a thing you can change. "There is no need to push it lower" implies you could. One of them gives you a reason to raise it and tells you what you would gain. A reader who follows those steps will look for the control, not find it, and conclude they are looking in the wrong place, because the page sounded like somebody who had used the app.

This is the third time I have audited a claim on this site against the constant behind it. The first time it was the cap, where 25 of 38 pages promised no limit. Then it was the thirteen pages that still said unlimited after I had supposedly fixed it. The pattern in all three is the same, and it is not that the facts went stale. It is that prose fields are the one part of a typed content system where nothing checks anything. interval: number would have been impossible to get wrong. body: string[] will hold any sentence a confident person types at midnight.

What I am doing about it

The honest fix is not one of these, it is both, and in this order.

First, the site stops describing a dial. Three edits: the FAQ answer becomes "every 30 seconds, for all of your searches in turn", and the two setup steps lose the sentence about choosing. That is the half I can do today, and it is the half that matters, because a buyer deciding on /pricing is reading the site, not the source.

Second, the number stops being a string in six files. The site cannot import the app, but it can hold its own copy of the product's facts in one typed module, and every page that wants to print the interval can read it from there. The thing I keep relearning is that a fact repeated 56 times is not 56 facts, and the moment it is written out by hand in prose it stops being checkable by anything except somebody doing what I just did.

As for the setting itself: I am not going to add it. A per-search interval sounds like a feature and is actually a scheduler, and the people who would reach for it would reach for it to slow a search down, which is the one direction the product has no interest in going. Thirty seconds, every search, in turn. That is what the app does and now it is what the site will say.

You can see the current state of all of this on /alerts, and the app itself is on /download.