A hit counter looks like a measurement. It has a number, a start date, and a table of “today / yesterday / total.” On a weather site it sat next to real instruments, so visitors treated popularity as a quality signal: many hits, therefore a serious station. That inference is false. A counter is a web-log gadget. It leaks, it inflates, and it has no units that belong in a climate record.
The historical TNET Weather page at /stat/counter.php was such a gadget. A recovered capture showed a PHP Web Stat 1.9 table (online, today, monthly slots, a maximum, an average per day, a running total, and a start date in 2008). This article explains how those counters were implemented—images, includes, and log files—and why the numbers leak or lie. It is not a live tally. It does not clone /visitors.php, which is the companion problem of treating traffic as provenance.
Historical context
Personal weather sites of the 2000s collected traffic the same way other hobby sites did. Operators pasted a third-party snippet, installed a PHP counter in a /stat/ folder, or hot-linked a remote “hit” GIF. The visual language was a dashboard: online users, daily totals, a grand sum. Some packages rendered the dashboard as an HTML table; others as a PNG or GIF so it could be dropped into any page like a banner.
/stat/counter.php was the script endpoint for one of those packages. The path sits under /stat/, which is the usual place PHP counters wrote their logs and images. Neighboring pages on the same host also mentioned Web-Stat.com snippets and a visitors page with maps. Multiple counters at once were common. Each counted a different event, reset on a different clock, and stored a different log. None of them measured rainfall.
TNET Weather does not run that PHP package at this URL, does not republish the captured totals as if they were still incrementing, and does not provide a replacement widget.
How image and log counters worked
Almost every public hit counter of that era was one of three mechanisms, sometimes combined.
Image beacons. The page included <img src="/stat/counter.php"> or a remote equivalent. The browser requested the image. The script incremented a file, then returned a 1×1 GIF or a rendered PNG that drew the new total. If the visitor blocked images, the count did not move. If a feed reader or a crawler requested the image, the count did move. The “measurement instrument” was whatever requested a URL, not a person.
HTML includes and iframes. A small PHP file printed a table and was included or framed into the layout. Each page view of the parent executed the include. Caching of the parent page could freeze the number; disabling cache made every refresh a new hit. “Online” counts usually meant “sessions seen in the last N minutes” in a lock file, not simultaneous humans.
Server log parsers. Access logs were scanned for GET lines. The counter displayed derived totals: today, yesterday, this month. Log rotation, timezone of the server, and whether bots were filtered decided the result. A “maximum 550” figure was a maximum of whatever the parser called a day, not a calibrated occupancy.
PHP Web Stat-style packages mixed these: a display table, a data-directory log, and often a cookie for return visits. The input is HTTP requests. The output is a derived popularity statistic with no printed error bars.
Why they leak
A counter that runs on your origin sees more than a number.
- IP addresses land in the log that backs “online” and “today.”
- User-Agent strings distinguish browsers, crawlers, and scripted clients—and also fingerprint people.
- Referrers show which forum, map, or school page sent the visitor. Weather sites collected those because operators liked to see Weather-Watch or a mesonet link in the log. Referrers are also other people’s URLs, sometimes with query tokens.
- Cookies that mark a returning visitor are identifiers. They are not weather metadata.
The leak is worse when the counter is a third-party image. Then the request goes to someone else’s host, with your page as referrer. A “free counter” in 2008 was often a tracking pixel with a public total as the user-facing excuse. Even a first-party /stat/counter.php can leak if the log directory is web-readable, if directory listing is on, or if the script echoes recent visitors into HTML.
Privacy pages on PWS sites often promised not to sell personal data while the footer still loaded a counter, an analytics GIF, and a visitor map. The privacy article is the policy URL. This page is the mechanism. A policy that does not mention the counter’s logs is incomplete.
Do not treat this as a how-to for scraping visitors. The only operational advice is: if you do not need the log, do not keep it world-readable, and do not paste a third-party beacon on an observation page.
Why they lie
Even as traffic statistics, hit counters are poor instruments.
Bots and feed fetchers look like hits. A mesonet poll every minute was counted as popularity.
Caches and CDNs hide hits. A cached page may not re-run PHP. An image cached by the browser will not increment on the next view. “Today: 0” next to “Total: 77164” is a compatible pair when the image is stale and the total file is not.
Double counting. A page with a footer counter plus a sidebar Web-Stat snippet plus an analytics GIF records three events per view. Operators added more snippets instead of removing old ones.
Resets and file corruption. Totals live in a writable text file. Restoring a backup, running two servers, or letting a crawler hit an install script can zero the sum or duplicate it. The start date on the widget is the date the file was created, not the date the station began.
“Online” is a sliding window, not occupancy. Five “online” could be one person plus four bots, or five tabs.
The number has no weather unit. It cannot be compared to a neighboring station’s counter, because the scripts differ. It cannot validate a temperature. A popular bad siting is still a bad siting.
So the counter lies in both directions: it inflates (bots, duplicates) and it deflates (image blockers, caches). It also lies by category, which is the important scientific failure: it presents a web-log derivative as if it were in the same family as the thermometer.
Distinct from /visitors.php
/visitors.php is the vanity-versus-provenance page: maps of hits, live visitor gadgets, and why a traffic picture is not a station history. This /stat/counter.php article is the implementation page: how the number was produced from images and logs, and why that production leaks and miscounts.
Do not merge them. One is about the social meaning of being watched and watching back. The other is about a PHP endpoint and a log file. A reader who needs to know whether to trust a total of 77,164 should start here. A reader who needs to know why a map of visitors is not evidence should start at /visitors.php.
Status is a third object. Last upload time is quality control for observations. A counter that still ticks while the ClientRaw file is twelve hours old is not a heartbeat. It is proof that browsers can fetch an image.
Practical checklist
- Do not put a hit counter on an observation template. It trains readers to confuse traffic with quality.
- If you need operational traffic data, use first-party logs with retention limits, not a public running total.
- Block
/stat/data directories from HTTP; a counter log is not a climate product. - Do not load third-party beacons on pages that publish personal-station locations.
- Never cite a counter in a paper, a CWOP note, or a station-history file as proof of representativeness.
- If you retire the gadget, leave this URL as an explanation rather than a dead table.
Modern relevance
TNET Weather’s public work is about evidence families: observed, modelled, and derived. A hit count is a derived web metric with unstated error, not a meteorological observation. The plain-language account is how the service works, the primary modern destination from this URL.
Source identity and quality control for weather and network records used in research are on data sources, quality controls, and methodology. That brief does not ingest PHP Web Stat files. The site-history hub and the legacy hub index the restored property without a public tally.
Sources
- W3C: Logging in the World Wide Web (historical common-log context)
- RFC 9110: HTTP Semantics (request/response as the actual event being counted)
- NWS
- TNET, How the service works
- TNET, Data sources, quality controls, and methodology