gpconf.neogy.dev
Reading level

Live tracker

Once a day a small job asks CelesTrak four questions and writes down the answers as numbers and yes/no. Nothing you do on this page contacts CelesTrak.

Daily counts from four CelesTrak endpoints and a weekly hash check of the 20 stable sources of the corpus that answer with data, computed by a scheduled job and served as static JSON. Derived measurements only: no element values are stored or shown.

Highest satellite number among recent launchesHighest catalog number in the last-30-days group

One step per day. The scale runs only from the lowest number in the chart to the highest, 100,789 to 101,142; the climb from 100,000 is on the story page. A shaded day has no value. The first point, in amber, comes from the test kit’s own data collection on 21 Sep 2026. The numbered points are milestones: slide or point to one to read it, listed under the chart.

One entry per day from /data/tracker/history.json. The vertical scale spans the window’s own values, 100789 to 101142, and does not start at zero. A day without a value is shaded and never bridged. The seed entry (amber) is the corpus’s Phase 2 fetch of 2026-09-21. Numbered points are milestones worked out from the record; the slider or a pointer reads any day, listed under the chart.

123456

21 Sep · 100,78923 Oct · 101,142

23 Oct 2026 highest numberhighest NORAD_CAT_ID 101,142 no value: that day’s request failedno value: the request failed no value: the daily check did not runno value: no tracker entry

  1. 121 Sep 2026 The record begins at 100,789, from the test kit’s own data collection.First entry, the seed: 100789, from the corpus’s Phase 2 fetch.
  2. 222 Sep 2026 No value: the request to CelesTrak failed that day, with error 500.No value: the request answered HTTP 500.
  3. 325 Sep 2026 Past 100,800: the number reached 100,822.First value at or above 100800: 100822.
  4. 47 Oct 2026 The biggest step in the chart: up 72 in a day, to 100,954.Largest one-day rise in the window: +72, to 100954.
  5. 514 Oct 2026 Past 101,000: the number reached 101,031.First value at or above 101000: 101031.
  6. 623 Oct 2026 The latest: 101,142.Latest entry: 101142.

Last successful check: 2026-10-23 11:47 UTC. 8 requests, 0 errors.

Current values

Highest satellite number among recent launchesHighest catalog number, last-30-days CSV

101,142

2026-10-23 11:47 UTC

Recent satellites with six-digit numbersSix-digit objects in that group

225 of 225

2026-10-23 11:47 UTC

The same list in the old formatlast-30-days TLE request

404

“not found”: none of them fit the old formatNo GP data found · 2026-10-23 11:47 UTC

Unidentified objects: new format vs oldAnalyst group, CSV vs TLE record count

592 vs 217

375 have six-digit numbers and are missing from the old format375 six-digit, 217 below 100000 · 2026-10-23 11:47 UTC

Nine-digit numbers in Starlink launch dataNine-digit ids in the Starlink SupGP feed

6 of 13 days

27 ids, then 26, after two launches, in daily checks from 2026-09-21 to 2026-10-04. Checking ended on 2026-10-04.

Did the “first ever” records change?gp-first stable-source drift (weekly)

0 drift

20 match · 0 drift · 0 error · 0 not yet checked of 20 · 2026-10-23 11:47 UTC

Count relations at the last run: TLE records = CSV records below 100000 for last-30-days: yes; for analyst: yes.

History

The other daily answers, one point per day, the first in amber as above.

The other daily measurements, the seed entry in amber. Each chart has a data table for screen readers; with scripts off, the whole history is one table.

The last two charts are a finished record. For a few days after each Starlink launch the new satellites carry nine-digit placeholder numbers. The job looked for them every day from 2026-09-21 to 2026-10-04 and found them on 6 days of 13. It has stopped looking: the file is large, and the answer was one yes or no.

The last two charts are a closed record. The job downloaded the Starlink supplemental CSV every day from 2026-09-21 to 2026-10-04: 1.8 MB, more than nine tenths of its daily bytes, for one count and one yes or no. The ids were present on 6 of 13 days, 27 ids, then 26, each spell taken to be one launch. A weekly check was the alternative; the two spells seen up to 2026-10-04 lasted at least four days and three, so a check every seven days would have missed a launch about half the time. The corpus’s own capture of 2026-09-21 holds the 27 ids of the first.

Six-digit objects in the last-30-days group
Loading…
last-30-days TLE request: 404 (slate: CelesTrak’s TLE format carries nothing above 69999 except the analysts in 80000–89999, as its documentation says; the normal state) or TLE data returned (green)
Loading…
Analyst objects in CSV
Loading…
Analyst objects in TLE
Loading…
Nine-digit ids in the Starlink SupGP feed, daily checks from 2026-09-21 to 2026-10-04, when checking ended
Loading…
Nine-digit ids present (green) or none (slate: the normal state outside the days after a launch); the record ends on 2026-10-04
Loading…

Stable-source drift

The test kit’s frozen answers rest on CelesTrak’s “first ever record” pages staying the same. Each week the job re-reads them and compares fingerprints. “Match” means unchanged.

The corpus assumes gp-first.php is stable (ambiguity gp-first-stability). The job re-fetches each of the 20 stable-tier sources that answer with data once every 7 days, at most 4 per day so the daily budget stays at 8 requests, and compares the SHA-256 with the manifest of v0.7.0. The corpus has two more stable sources, the first-record TLE requests for two six-digit objects, which answer HTTP 404 with the 16-byte body No GP data found. They were re-checked until S-083 and matched every time; the job no longer asks, since CelesTrak states that a 404 does not change by repeating the request.

20 stable sources
sourcecaselast checkedresult
gp-first-25544-TLEepoch-year-19xx2026-10-23 11:47 UTCmatch
gp-first-25544-2LEepoch-year-19xx2026-10-21 11:59 UTC · error 2026-09-22 06:44 UTCmatch
gp-first-25544-CSVepoch-year-19xx2026-10-21 11:59 UTC · error 2026-09-22 06:44 UTCmatch
gp-first-25544-JSONepoch-year-19xx2026-10-23 11:47 UTC · error 2026-09-22 06:45 UTCmatch
gp-first-25544-JSON-PRETTYepoch-year-19xx2026-10-23 11:47 UTCmatch
gp-first-25544-XMLepoch-year-19xx2026-10-17 10:53 UTCmatch
gp-first-25544-KVNepoch-year-19xx2026-10-23 11:47 UTCmatch
gp-first-100000-CSVsix-digit-omm-saramago2026-10-20 11:48 UTCmatch
gp-first-100000-JSONsix-digit-omm-saramago2026-10-20 11:48 UTCmatch
gp-first-100000-XMLsix-digit-omm-saramago2026-10-21 11:59 UTC · error 2026-09-22 06:44 UTCmatch
gp-first-100000-KVNsix-digit-omm-saramago2026-10-21 11:59 UTCmatch
gp-first-270449-CSVanalyst-objects2026-10-17 10:53 UTCmatch
gp-first-270449-JSONanalyst-objects2026-10-17 10:53 UTCmatch
gp-first-270449-XMLanalyst-objects2026-10-19 13:31 UTCmatch
gp-first-270449-KVNanalyst-objects2026-10-17 10:53 UTCmatch
gp-first-81011-TLEanalyst-objects2026-10-20 11:48 UTCmatch
gp-first-81011-CSVanalyst-objects2026-10-19 13:31 UTCmatch
gp-first-81011-JSONanalyst-objects2026-10-20 11:48 UTCmatch
gp-first-69999-TLEbstar-and-derivative-forms2026-10-19 13:31 UTCmatch
gp-first-69999-CSVbstar-and-derivative-forms2026-10-19 13:31 UTCmatch

How the tracker works

  • A scheduled job runs once a day on GitHub’s servers, not in your browser.
  • It asks CelesTrak for four pages, each once, and never more than eight a day including the weekly checks. It identifies itself by name and by this site’s address.
  • It keeps only counts, yes/no answers, times and fingerprints, then saves them as small files that this page reads.
  • If CelesTrak gives an answer the job did not expect, the job stops asking for the day and records that, and this page shows the last good values with their dates.
  • Endpoints, once per run: /NORAD/elements/gp.php?GROUP=last-30-days&FORMAT=CSV; /NORAD/elements/gp.php?GROUP=last-30-days&FORMAT=TLE; /NORAD/elements/gp.php?GROUP=analyst&FORMAT=CSV; /NORAD/elements/gp.php?GROUP=analyst&FORMAT=TLE. Plus at most 4 gp-first.php drift checks. Hard cap 8 requests per run, one run per day; a repeated URL raises before anything is sent.
  • User-Agent: gpconf-site/0.1 (+https://gpconf.neogy.dev; scheduled tracker, at most 8 requests per day; https://github.com/hneogy/gp-omm-conformance). No redirects followed, no retries, 2 s between requests, a 404 is recorded and never repeated (CelesTrak’s policy: 50 errors in two hours leads to a firewall entry). The job expects one 404 a day, from the last-30-days TLE request, and no other: that request is how this page still sees what CelesTrak answers when a group holds no object below 100000.
  • Stored per source: HTTP status, byte count, SHA-256, timestamp; per measurement: counts and booleans. Raw bodies are not written anywhere in CI. The tests assert that no element value can appear in the outputs.
  • Failure handling: the first answer the job did not expect ends the run. A measurement that got one is ok: false with the error class, the ones after it are stored as not requested, no re-check is made, and the run is “partial” or “failed”. A re-check that got one is recorded as an error, and the re-checks after it stay due. The day after an HTTP 403 or 429 the job makes no request. latest.json carries the last successful value per measurement with its timestamp; the page shows both.
  • Data files: latest.json, history.json, drift.json (CORS-enabled, cached ten minutes). Job source: jobs/tracker.py in the site repository.