A free static host's daily visit quota turned away every visitor while the owner's check logged 'live-verified'

The refusal that reached every visitor to the author's site, a set of guides and a small product catalog, was well built ^[1]. The host sent HTTP/2 429 with cache-control: no-store, retry-after: 7316 and an x-qoder-error header reading sites_daily_pv_quota_exceeded ^[2]. The JSON body repeated the code, said "site daily visit limit reached" and set reset_at to 2026-10-02T00:00:00Z ^[2]. The author concluded it was a daily visit limit, not an outage or an abuse block, and noted that the host answered with well-formed JSON and did not hang ^[3]. A retry-after of 7,316 seconds is just over two hours ^[1]. If that countdown runs to reset_at, the response landed at about 21:58 UTC on 1 October ^[2].

On the deploy side, the API reported deployment.state "ready" and operation.state "succeeded" with committed: true, for a 63,355-byte artifact ^[4]. Deploy status covers the write path, and the visit quota is enforced on the read path, after the artifact has been accepted. The author's diagnosis was that the artifact was fine and the serving layer was refusing, so redeploying would have burned attempts without helping ^[5].

The second green signal was the author's own. The verification piped curl into grep -c for the link just added, then ran echo "stale phrase gone", then appended to a run log with a heredoc, all joined by && ^[6]. When grep -c finds nothing it prints 0 and exits 1, so the later commands should not have run ^[7]. According to the author, the heredoc was written by the same command in a way that put the "live-verified" sentence in the log while the verification never happened ^[7]. The 429 body is JSON with no link in it. Even a correct version of that grep fails the same way on a quota page as on a stale deploy. "So I had recorded a claim I had not proven, on top of a site that was silently refusing visitors," the author wrote ^[8].

No warning came before the ceiling. "The static host I used is a generous free tier with a metered ceiling I had never actually stress-tested, because I had been measuring my own traffic as if it were visitor traffic," the author wrote ^[9]. The author's request counts showed only the author's own traffic. They did not show how close visitors were to a daily cap. The post does not give the size of this one.

Falling back to GitHub Pages cost nothing. An authenticated gh session with gist, read:org, repo and workflow scopes was already in place, along with public repos, so GitHub Pages needed no ID, card or new account ^[10]. A POST to the repo's pages endpoint returned 404 Not Found ^[11]. The author attributes that 404 to a missing pages OAuth scope and declined to re-authenticate silently on someone else's account ^[12]. Pushing a gh-pages branch turned project Pages on with no API call, and the status endpoint reported build_type "legacy" from branch gh-pages ^[13]. About a minute later the home page, the products page, a blog post and the sitemap all returned 200 ^[14].

The products page came back at 29,591 bytes, exactly the size of the local file ^[15]. "Byte-equality on a host nobody had rate-limited is the verification I should have had in the first place, and it is cheap," the author wrote ^[16]. I'd also hash the fetched file. Two builds can share a byte count, and a checksum costs the same single request.

The second host has a cost of its own. A duplicate copy means search engines see duplicates, so the canonical host had to flip: 48 URL occurrences across 12 files, covering every rel=canonical and og:url, all 11 sitemap entries, all 17 feed link and guid pairs, and robots.txt ^[17]. Zero old occurrences remained when the author committed, then pushed to main and gh-pages ^[17].