A weather website can return HTTP 200 while the thermometer has been silent for six hours. The page is up; the observation is dead. The status that matters for science is not whether a ping reaches the web host. It is whether the logger is producing samples and whether those samples have been published within the interval the operator claimed.
The historical TNET Weather page at /status.php used the word “status” in public. A recovered capture showed third-party packet-loss charts for the server, not a live logger console. That is useful history: operators often measured the wrong layer. This article keeps the URL and teaches the layer that quality control actually needs—last upload time and logger health—without drawing a fake dashboard or claiming the Mesa station is being monitored now.
Historical context
Personal weather sites advertised “live” in the menu because the selling point was freshness. Weather Display and similar programs wrote a last-updated timestamp into HTML, uploaded clientraw.txt on a schedule, and sometimes exposed a separate status or “server” page. Hosting trouble was common enough that a status URL felt responsible: if the graphs looked frozen, was it the ISP, the PC, or the instruments?
The recovered /status.php page answered with network reachability. It embedded ping-loss and latency charts from a consumer broadband-monitoring service, labeled by U.S. regions, for the host that served the site. That is a statement about path to the web server. It is not a statement about the Davis-class logger in the yard, the serial or USB link, or the age of clientraw.txt. A server that answers pings can still be publishing yesterday’s file. A server that drops pings can still have a logger filling a local disk.
TNET Weather does not replay those charts, does not publish historical host addresses, and does not operate a public status board at this path. The restored page is an explanation of stale-data control.
Last upload is the status that matters
For a published observation, freshness is part of the measurement’s meaning. A temperature labeled “now” with a timestamp of 14:03 is an observed value at 14:03. The same number shown at 20:03 without a new timestamp is a stale display of an old observation. The scientific fix is not a smoother gauge. It is to print the last-upload or last-sample time in an unambiguous timezone and to refuse the word “current” when that time is older than the promised interval.
Useful status fields on a PWS site are therefore small and boring:
- Last sample time at the logger (instrument clock).
- Last successful publish time of the public file (host clock).
- Expected interval (for example, one minute or five minutes), stated as a claim, not as a measured uptime percentage.
- Which file is the source (
clientraw.txt, a realtime file, a vendor JSON).
Clock disagreement is itself a quality flag. If the logger says 14:03 and the file’s filesystem mtime says 18:40, you do not know which clock drifted. You know the pair is not trustworthy until it is explained.
Official observing practice treats timeliness as part of data quality, not as a website amenity. WMO instrument guidance is about making measurements comparable; a sample without a usable time is not comparable. Hobby sites implement the same idea with a footer timestamp. When that footer is decorative, the observation is unlabeled.
Logger up is not the same as website up
Three systems fail independently.
Logger / console. Power, radio link from an integrated sensor suite, serial/USB, or a preprocessing helper that shares the port among programs. If this layer is down, there is no new observation. The website may still show the last good file.
Publisher PC. Weather Display or another station program, disk, and the upload job (FTP, SFTP, or a copy to a local web root). If this layer is down, the logger may still be recording locally while the public file ages.
Web host and network. HTTP service, DNS, TLS, and the path from visitor to host. If this layer is down, visitors see an error; the logger may be fine. If this layer is up, visitors see a page that may be stale.
A ping-loss chart only sees the third layer, and only as reachability from a third-party probe, not as “the observation is fresh.” HTTP 200 only sees that some document was served. A hit counter that still increments only sees that a browser requested an image. None of those is logger status.
“Logger up” therefore means: the instrument chain is producing samples at the expected cadence. You establish that from the sample timestamps in the published file, from a local log, or from an independent ingest (for example CWOP) that stamps receipt time. You do not establish it from a green badge on a status page.
Stale data as quality control
Staleness is a quality-control flag, the same family as a missing value or an out-of-range spike. Handling it well is a short policy, written in public:
- Define stale. “Older than twice the upload interval” is a clear rule. Hidden thresholds that change with marketing needs are not.
- Show the time anyway. Replacing a stale temperature with a blank or with “data delayed” is honest. Replacing it with a neighboring airport METAR without a label is a silent substitution.
- Do not interpolate across a gap on a “current” page. Fill methods belong in climate products with a method note, not in a live table.
- Carry the flag downstream. A banner, a parser, and a mesomap that all read the same file must all honor the same age check. Otherwise the text page says stale and the Flash console still looks live.
- Record the outage on the station news or configuration log as a gap, not as weather.
NOAA MADIS quality control for citizen observations compares stations to neighbors and to model background; it is an independent check. A local stale flag is a prior, weaker check: “this number is too old to use as now.” Both can be true at once. Neither belongs in a decorative uptime graphic.
TNET’s public research language treats freshness as part of source quality. The place that states that discipline without internal thresholds is data sources, quality controls, and methodology. That page is the primary modern destination from this URL.
This page is not a live monitor
This URL must not be read as a current operations board.
- No packet-loss charts are shown here.
- No “all systems operational” table is implied.
- No upload clock for a present-day Mesa station is published.
- No TNET internal probe, score, or fallback rule is documented.
A fake dashboard would be worse than a missing one: it would look like evidence. Historical status pages that embedded third-party grapher URLs also aged into broken images, which visitors could mistake for an outage of the station rather than an outage of the chart vendor. Restoration that replayed those images would repeat the error.
If you need official hazards, use NWS or your national meteorological service. If you need a historical map of this property, use the legacy hub and the site-history hub.
Practical checklist
- Print last-sample and last-publish times on every observation view, with timezone.
- State the expected interval once, on the configuration page.
- When age exceeds the interval, label the values stale; do not rely on a ping chart.
- Keep website reachability (if you measure it) on a clearly named network page, not labeled as station status.
- Do not paste third-party monitor images as proof the logger is up.
- After an outage, leave a gap in the series and a line in the site-news log.
Modern relevance
Connection-intelligence work still has to refuse stale inputs: a weather field or a network measurement that is too old for the interval under discussion is not “current evidence.” How TNET describes observed versus modelled versus derived information is how the service works. How source freshness is treated conceptually for public records is the methodology brief linked above. This /status.php article does not publish internal gating rules, and it does not simulate a monitor.
Related historical pages: station configuration as metadata and published-data identifiers. Hit counts on /stat/counter.php are not status.