Skip to main content
← Planes

Flight Data Recovery

This page exists because of a claim: that flight records central to this case were erased. We took that claim seriously enough to act on it as a working assumption, went looking for backups of the data, and wrote down what we found — including the parts that did not go the way the claim predicted.

The sweep has now been run across the whole fleet — all sixteen aircraft, on five tracking sites and four independent archives. The short version, stated plainly because it is not the answer the claim predicted:

Nothing has been found to have been removed from any public tracking site. Every aircraft page in this investigation loads today. What was recovered instead is a large amount of flight data that nobody on this site had ever held — including the first testable primary record of the alleged following-flights themselves.

What did come back is substantial. The flight-history table for the tail number at the centre of the dispute was recovered from an archived copy taken the day after the assassination. Days the primary archive refuses to serve were recovered from two independent backups that agree with each other to the second. Flight tracks from 2022 — a year this site has published as untestable — were recovered for the first time, and put three of the five claimed clustering states on primary position data. 153 flight legs that our own tooling had recorded as zero turned out to be sitting on disk unparsed. And all 85 claimed overlaps have now been checked against primary position data: 24 have the aircraft where the claim said it was, and 12 do not — tested one at a time on Overlap Recovery and under Overlaps.

Four of the findings on this page correct this site rather than anybody else. They are marked as corrections where they appear, and they are the reason the rest of it is worth reading.

Correction: the FlightRadar24 "removal" does not survive its own control test

This page previously stated that N102DZ's FlightRadar24 page was "A REAL REMOVAL, DOCUMENTED", on the evidence that the URL returns HTTP 403. That was wrong, and this section is the retraction.

The 403 was real. What it meant was not. FlightRadar24 returns HTTP 403 to any scripted request, whichever aircraft is in the URL. When the identical script was pointed at five aircraft chosen for having nothing whatever to do with this case — a Ryanair 737, a Lufthansa A380, a Delta Connection CRJ, an American A320, and Nike's corporate Gulfstream — all five came back 403 as well.

A second, wider control run on 24 August 2026 closed the question. The same script was pointed at all thirteen case tails, at seven further unrelated aircraft — N628TS, G-EUUU, VH-OQA, N509AY, D-AIBA, N1, EI-DYY — and then at two URLs that are not an aircraft page at all:

ProbedHTTP
flightradar24.com/data/aircraft/n102dz403
The other case tails — su-btt, su-bnd, su-btu, su-btv, su-bgm, n888kg, n40jd, n560tw, n582mm, n872ra, n1098l, t7-ell403, every one
The seven unrelated control aircraft403, every one
https://www.flightradar24.com/FlightRadar24's own home page403
https://www.flightradar24.com/data/aircraft — the aircraft index403

Every one of those responses carries the same body, about 5,877 bytes. FlightRadar24 returns 403 to a script for its entire site, including its own front page. A response that is byte-identical for the front page cannot distinguish a removed record from a present one. By script, the removal question is not answered badly — it is UNTESTABLE. The method cannot see it. That reasoning about the script is right and it stands. What has changed since it was written is that a method which can see the question has now been used — twice, independently — so the standing of the removal claim is no longer "untested" but refuted. See below.

That is the correction underneath the correction, and it deserves to be said on its own: this page reported the N102DZ removal more strongly than the evidence supported, and what caught it was a control test — asking an unrelated aircraft, and then a home page, the same question. No argument about anybody's motives was involved, and none was needed.

Testing the question properly needs a real browser session, which is Pass 4, browser_capture/. That pass has since been run. The same pages were opened in an ordinary browser, where Cloudflare's robot check is satisfied:

Asked howN102DZThe 15 other aircraft here4 unrelated control aircraft
By script403403, every one403, every one
By browser200, page loads200, every one200, every one

The browser served N102DZ's page complete with its identity block — Gulfstream V · GLF5 · Mode S A00C85 — on 24 August 2026. The page is not gone. It was never gone.

That run was then reproduced by a second, independent browser session on the same day, because a conclusion this load-bearing needed checking by someone other than the person who reached it. Six probes — N102DZ, SU-BTT, SU-BND, N888KG and two unrelated controls — all fetched same-origin from inside one real logged-out session. HTTP 200, every one. N102DZ returned page title N102DZ - Gulfstream V [555] - Flightradar24, MODE S A00C85, TYPE CODE GLF5, and nothing on the page says removed, blocked, restricted or unavailable. Both runs are on disk: browser_capture/captures/fr24_page_availability_2026-08-24.tsv and browser_capture/captures/fr24_n102dz_removal_test_2026-08-24b.tsv.

The claim "N102DZ was removed from FlightRadar24" is therefore REFUTED — not untested.

The empty flight table is a paywall, not an erasure. FlightRadar24 shows a logged-out visitor the last seven days only, and prints so under the table: "More than 7 days of N102DZ history is available with an upgrade to a Silver (90 days), Gold (1 year), or Business (3 years) subscription." That line appears on every one of the twenty pages probed, subject and control alike. N102DZ's table is empty because a private aircraft that has not flown in a week has nothing to show — and Nike's Gulfstream, the control, is empty for the same reason on the same day, while the Ryanair 737 flying six sectors a day shows 683 rows.

The second run made that control tighter still. The unrelated aircraft N628TS prints the identical "could not find data for specified flight" message at 53,318 bytes, against N102DZ's 53,310 — a difference of eight bytes between an aircraft at the centre of this case and one with no connection to it. SU-BTT, SU-BND and a Ryanair control all render history on the same day, because they had flown recently. An empty table on FlightRadar24's free tier means the aircraft has not flown in seven days. It does not mean anything was deleted.

The limit, and it travels with the refutation everywhere it is published. A page that loads today cannot testify about what its table held in May 2026. "The page was taken down" is refuted. A narrower claim — that history was specifically purged and later restored — is beyond this method in either direction, and no page on this site may assert it. A logged-out free tier is also the weakest view FlightRadar24 offers: a paid tier shows 90 days to 3 years, and we have not looked through one.

This matters more than the finding it replaces. The standard this page set for the other "erasures" is the standard that just took this one down. The evidence is at browser_capture/captures/fr24_page_availability_2026-08-24.tsv and in page_control_probe.json, and the method is set out on What A 403 Actually Means.

The things called "erased", separated

WhatStatusWhat it actually is
N102DZ's FlightRadar24 page, asked by scriptUNTESTABLE BY THIS METHOD — superseded by the row belowFR24 returns 403 to a script for its own home page, its aircraft index, and seven unrelated control aircraft, with the same ~5,877-byte body every time. That 403 is bot protection. It can neither confirm nor refute a removal, and this page previously read it as though it could. It is not the standing of the claim — the browser row is.
N102DZ's FlightRadar24 page, asked by browserREFUTED — not a removalOpened in a real logged-out browser on 24 Aug 2026 the page returns HTTP 200 with its identity block intact, as do all fifteen other case aircraft and all four browser controls, and an independent second session the same day reproduced it. The empty table is FR24's seven-day free-tier limit — the unrelated control N628TS prints the same message at 53,318 bytes against N102DZ's 53,310. Limit: this cannot testify about what the page displayed in May 2026, and no page here may claim a purge-and-restore in either direction.
The adsb.lol 403 band, from 12 Oct 2025NOT a removalThe archive returns 403 for every aircraft, controls included, beginning exactly at 2025-10-12. The same days are published in full as public backup files.
The adsb.lol 404 stretch, to about 1 Aug 2026NOT a removalArchive-wide. Every unrelated control airframe 404s identically across the same seven months, and normal service resumes about 2 Aug 2026.
Erika Kirk's own itineraryStill absent, and no archive fixes itNot a tracking-site question at all. No dated list of her locations has ever been published, so there is nothing for a backup to restore.

Every one of the tracking-data "erasures" was tested against control aircraft chosen precisely because they have nothing to do with this case, and every one failed the same way the controls did. That is what tells you it is the archive, or the paywall, or the bot filter — and not the airframe.

Read the first two rows together, because the difference between them is the whole method. One says our tooling is blind to the question; the other says that when a tool that can see the question is used, the answer is that nothing was removed. Those are two different statements and collapsing them is exactly the mistake this page made the first time. The second row is the one that gives the claim its standing: refuted.

The one thing on the list that genuinely has not been recovered is the last row, and it is the one no amount of ADS-B work can touch: an aircraft track never establishes who was aboard. See Erika Flight Logs Erased.

The whole fleet, swept

Sixteen aircraft. Five tracking sites each. Four independent archives each. Every result is a file on disk under site/docs/Planes/<TAIL>/data/recovered/, with the source in the filename, so any line below can be checked without trusting this page.

Aircraftadsb.lol daysairplanes.live daysADSBX sample daysArchived pages heldFlight rows off archived pagesPage removals found
N102DZ125018313none
N1098L1746193none
N2100L829173none
N40JD1012111none
N559060001none
N560TW9272329none
N582MM192423740none
N59906926234none
N872RA1248240none
N888KG412132270none
SU-BGM25116none
SU-BND19276211none
SU-BTT293760none
SU-BTU03914none
SU-BTV1720none
T7-ELL526120none
Total15637920750153none

Read the last column first. It is empty for every aircraft. Across sixteen airframes and eighty aircraft-page probes there is not one page that was public and is not public now.

Read the second-to-last column next, because it is the one that gained something. 153 rows of published flight history were pulled back out of archived copies of pages that no longer show that history to a logged-out visitor — not because it was removed, but because it aged past the free seven-day window. The Internet Archive kept a copy of the table on the day the crawler happened to visit, and for N888KG the crawler visited twenty-two times.

The full breakdown, aircraft by aircraft and source by source, is on Per-Aircraft Recovery Status.

Every alleged overlap, tested

The 73-overlap claim is a spreadsheet: on this date, this Egyptian government jet was in this American city, where a Kirk was. Most of those rows have never had a primary flight record behind them at all. All 69 of them were pulled against both free daily archives, on the alleged day and the UTC day either side.

Alleged (aircraft, date) pairs tested69
Now have a real ADS-B track on the alleged day23
Track exists only on a neighbouring day7
No free archive holds anything in the window39
Of the 23 testable: track puts the aircraft in the alleged country21
Of the 23 testable: track puts it somewhere else entirely2

Twenty-one of twenty-three check out, and often to within two kilometres of the named airport — SU-BTT arriving Wilmington 1.63 km from KILG on 6 April 2023, Provo 1.42 km from KPVU on 23 April 2024. Two do not: SU-BND is alleged in St. Louis on 12 May 2023 while the recovered track flies Paris Le Bourget to Inshas Air Base in Egypt, and SU-BTT is alleged in Nebraska on 18 June 2025 while the track never leaves Egypt.

None of that makes the shadowing claim true. It makes the flight legs real, which is a different and much narrower statement — the same split this investigation's own audit keeps finding. A track showing SU-BTT at Wichita says nothing about where anybody named Kirk was that day. Every row, with the recovered position and the distance attached, is on Overlap Recovery.

The complete run: all 85 rows, verdict by verdict

The pass above tested 69 (aircraft, date) pairs. The register has since been checked in full — every one of the 85 rows of following/overlaps.csv, against both free archives on the claimed date and the day either side, resolving each position to the nearest airport in the public-domain OurAirports gazetteer with a 15 km radius. This is the fuller and stricter run, and it is the one to quote.

VerdictRowsWhat it means
AT_CLAIMED_AIRPORT24The claimed aircraft really was at the claimed field.
ELSEWHERE12Tracked that day, and somewhere else. Refuted.
NOT_HEARD22The archive covers the date; no trace for that airframe. Not a refutation.
NO_ARCHIVE_COVERAGE20No free archive reaches the date. Says nothing either way.
NO_TAIL_CLAIMED2The source row names no aircraft.
NO_DATE_CLAIMED5The five UNPUB- rows. Uncheckable by anyone, including their author.

Of the 36 rows that could be decided, 24 are corroborated and 12 refuted. Published audits of this spreadsheet said roughly two rows in three were wrong. Against primary position data it is the other way round — and this is the first time the sheet has been tested against position data rather than against somebody else's reading of a website.

Now the limit, and it is as important as the number. AT_CLAIMED_AIRPORT confirms the aircraft half of the pairing. It does not put a Kirk anywhere. An overlap needs both halves. The Kirk half is unchanged by any of this work: thin for Charlie, and close to empty for Erika, whose flight logs are reported erased — see Erika Flight Logs Erased. A confirmed aircraft must never be reported as a confirmed overlap.

Note also what the middle two rows are not. NOT_HEARD and NO_ARCHIVE_COVERAGE refute nothing. An archive that heard nothing is an archive that heard nothing; only ELSEWHERE refutes a row. The counts themselves — 73, ~23, 72, 70+, 68, 29 — remain disputed and unreconciled, and nothing here averages them.

The per-row verdicts, each with its own page, are under Overlaps. The raw extract is site/docs/Planes/following/apis/public_open_source/data/overlap_verification/overlap_verification.json.

The counterargument, stated in the same breath. Duncan Aviation holds Egyptian Air Force maintenance work and has plants at Lincoln and at Provo, which is an ordinary and sufficient reason for an Egyptian-registered jet to sit at either field. A confirmed landing is consistent with shadowing and equally consistent with a scheduled airframe visit to a maintenance shop, and this data cannot separate the two.

N102DZ, question by question

N102DZ is the Kirk family aircraft — a Gulfstream V, ICAO hex A00C85. Researchers reported in July 2026 that its public tracking history had been removed from FlightRadar24 in May 2026, which is the subject of Erika Flight Logs Erased.

Here is what we can now state with the evidence attached:

QuestionAnswerEvidence
Was the FR24 page public before?YesThe Internet Archive holds snapshots from 26 May 2022 and 11 Sep 2025 05:57 UTC.
Did it carry a real flight-history table?YesThe 11 Sep 2025 snapshot contains 11 flight rows covering 4–10 September 2025, recovered in full below.
Is it public now?YesThe page loads HTTP 200 in a browser on 24 August 2026, with its identity block intact. The 403 our script got is a robot block — see the correction above.
Does the public page show the old history?No — and it never didFR24 gives a logged-out visitor seven days. Everything older has always been behind a Silver/Gold/Business subscription. The multi-year history the overlap spreadsheets were built from was never on the free page.
Was the underlying ADS-B record destroyed?NoThe aircraft's tracks are still retrievable from independent archives, including throughout May 2026 itself — 50 days of them are on disk in this repo.

The last two rows are the ones that matter, and both cut against the dramatic reading. Nothing was removed from the world, and the thing people went looking for on the free FR24 page was never there to remove. The data is in networks FlightRadar24 does not control, and anybody can pull it.

The recovered table

This is the content that is no longer publicly retrievable from FlightRadar24, recovered from the Internet Archive's copy captured at 11 September 2025, 05:57 UTC — roughly twenty hours after the assassination. Times as FR24 published them, in UTC, with local times computed alongside. Scottsdale is MST (UTC−7), Utah is MDT (UTC−6), California is PDT (UTC−7).

DateFromToDurationActual off (UTC)Actual on (UTC)Local
04 Sep 2025Scottsdale (SCF)New Braunfels (QQZ)1:4419:3021:1412:30 MST → 16:14 CDT
04 Sep 2025New Braunfels (QQZ)Dallas (DAL)0:5023:3100:2118:31 → 19:21 CDT
05 Sep 2025Dallas (DAL)Scottsdale (SCF)2:1400:5603:1119:56 CDT → 20:11 MST
07 Sep 2025Scottsdale (SCF)Los Angeles (LAX)no actual time recordedstatus "Unknown"
08 Sep 2025Phoenix (PHX)Los Angeles (LAX)1:0300:1801:2117:18 → 18:21 PDT
08 Sep 2025Los Angeles (LAX)Scottsdale (SCF)0:5402:5003:4519:50 PDT → 20:45 MST
10 Sep 2025Scottsdale (SCF)Salt Lake City (SLC)1:1114:1215:2307:12 MST → 09:23 MDT
10 Sep 2025Salt Lake City (SLC)Scottsdale (SCF)1:1319:0020:1313:00 MDT → 13:13 MST
10 Sep 2025Scottsdale (SCF)Provo (PVU)0:5920:3121:3113:31 MST → 15:31 MDT
10 Sep 2025Provo (PVU)Camarillo (QTC)1:3822:1023:4816:10 MDT → 16:48 PDT
10 Sep 2025Camarillo (QTC)Provo (PVU)1:1100:21 (11th)01:32 (11th)17:21 PDT → 19:32 MDT

The same snapshot also carries FlightRadar24's own aircraft-identity fields, which settle a characterisation this site had been carrying as unconfirmed:

AIRCRAFT Gulfstream V · TYPE CODE GLF5 · MODE S A00C85 · AIRLINE Private owner · page title N102DZ - Gulfstream V [555] - Flightradar24

That is a tracking-site database entry, not a registry record, so the FAA registry still outranks it — but it is a contemporaneous, archived, third-party entry and it says Gulfstream V.

What the recovered table corrects on this site

This is the part that matters more than the drama. The recovered record does not only support what was already published here. It corrects it.

The N102DZ page has carried this description of the afternoon: the aircraft "arriving into Scottsdale at ~1:13 p.m. local, departing again immediately at ~1:13 p.m." — an odd, suggestive detail, a plane that supposedly touched down and left in the same minute.

The archived table shows what happened. The Salt Lake City → Scottsdale leg has a flight duration of 1:13 and it landed at 13:13 Scottsdale local. Those two numbers are the same by coincidence, and the "departed again immediately at 1:13" reading appears to be FlightRadar24's duration column being read a second time as a clock time.

The actual next departure from Scottsdale was 13:31 MST. The aircraft was on the ground for about eighteen minutes, which is a fast turn and is worth noting on its own — but it is not the zero-minute turnaround the site has been describing, and the difference came out of the recovered data rather than out of an argument.

A recovered record that only ever confirmed what we already believed would be a reason to distrust the recovery. This one did not.

The strongest-looking removal in the dataset, and how it dissolved

Everything above is about a claim other people made. This section is about the best removal candidate this page found on its own — and it did not survive either.

The Internet Archive holds fourteen FlightRadar24 captures of the N888KG page. Read as a sequence they look like a record being pulled:

Snapshot (UTC)BytesFlight-history table
11 Sep 2025 06:1463,886POPULATED
11 Sep 2025 09:2863,886POPULATED
11 Sep 2025 21:5163,886POPULATED
12 Sep 2025 16:3063,886POPULATED
13 Sep 2025 00:0563,886POPULATED
18 Sep 2025 04:0856,647empty
18 Sep 2025 13:2756,647empty
18 Sep 2025 15:2656,661empty
18 Sep 2025 19:2356,647empty
19 Sep 2025 06:0256,647empty
20 Sep 2025 14:4656,647empty
2 Nov 2025 17:4557,088empty
28 Jan 2026 22:0657,102empty

Same URL, same site, every capture HTTP 200, and the page gets 7,239 bytes lighter exactly once — between 13 and 18 September 2025, the week after the assassination. That is as close to a documented scrub as anything in this investigation has looked.

It is not one. The empty captures say why, in FlightRadar24's own words, printed where the table used to be:

"Sorry, but we could not find data for specified flight. More than 7 days of N888KG history is available with an upgrade to a Silver (90 days), Gold (1 year), or Business (3 years) subscription."

It is the free tier's seven-day history window, and nothing else. The 10 September 2025 flight was visible on 11, 12 and 13 September because it was still inside seven days. By 18 September it had rolled out of the window. Every FR24 capture we hold of this aircraft is consistent with that window and inconsistent with nothing. The two rows always present in the populated captures are the same two rows; the byte drop is the table markup going away, not a record going away.

We are publishing this because it is the strongest material we had and we lost it. A page that only ever reports the findings that survive is a page you should not believe. The captures are on disk under site/docs/Planes/N888KG/data/recovered/, with the snapshot timestamp in every filename, so a reader can check that the paywall sentence really is in the empty ones.

Do not merge this with the Wendover thread. The N888KG departure from Wendover is a separate claim about a separate question, and nothing here bears on it.

153 flight legs were on disk the whole time, recorded as zero

This is a correction to our own tooling rather than to a claim, and it changes what several other pages rest on.

The earlier harness wrote flight_rows_recovered: 0 into twenty FlightRadar24 sidecars and null into nineteen FlightAware ones. Both numbers were wrong. The FlightRadar24 parser was matching a row shape those pages do not use, and the FlightAware captures were never parsed at all. The archived HTML had been downloaded correctly and saved correctly; nothing read it.

code/extract_wayback_flights.py re-extracts all of it and rewrites the sidecars:

SourceFilesRows recovered
FlightRadar24 (server-rendered data-row table)2044
FlightAware (legacy pre-2017 tables)22109
Total42153

A zero in a provenance record reads as an absence of evidence. Here it was an absence of parsing. Anything on this site that rested on those zeros has to be re-read, and that is a bigger correction than it sounds, because a zero is exactly the shape a scrub is supposed to leave.

Six modern FlightAware captures really are empty, and they are now labelled honestly. They are a JavaScript shell — about 458 KB of page chrome around a trackpollBootstrap blob with no server-rendered rows — and they carry the state JAVASCRIPT_SHELL_NO_SERVER_RENDERED_ROWS rather than "0 rows". Nine FR24 captures are the seven-day-window empties described in the section above.

What came back out:

AircraftSnapshotWhat the archived page held
SU-BNDFR24, 12 Oct 20257 legs, 5–12 Oct 2025 — including Sharm el-Sheikh (SSH) → Giza/Sphinx (SPX) → Cairo on 5 Oct and Cairo → Jeddah on 7 Oct.
SU-BNDFR24, 18 Nov 20254 legs, Cairo ↔ Antalya, all on 13 Nov 2025.
SU-BTUFR24, 31 Aug 20224 legs on 26 and 28 Aug 2022 — Cairo, and El Alamein (DBB).
SU-BGMFR24, 7 May 20206 legs, including Cairo → Paris Le Bourget on 3 May 2020 and Goose Bay → St. Louis → Alton on 4 May 2020.
N560TWFlightAware, 29 Nov 20169 legs across KSDL, KPVU, KSLC, KELP, KTUS and MMSD.

Two of those are worth a sentence each, in opposite directions.

The SU-BND October 2025 legs came off a page that today returns 403 to a script — recovered content, from the same FR24 that our scripted method cannot see at all. They are the first published flight legs this repo holds that name Sharm el-Sheikh for a fleet aircraft, and they are for SU-BND on 5 October, which is a different aircraft on a different date from the SU-BTT tarmac claim of 13 October discussed further down. They do not corroborate that claim and must not be cited as though they did.

The SU-BGM May 2020 legs and the N560TW 2016 legs both cut against novelty. Cairo → Le Bourget → Goose Bay → St. Louis is the same routing shape the 2022–2025 legs use, flown five years before this case existed. And N560TW was flying Scottsdale–Provo–Salt Lake City in November 2016 — nine years before the Scottsdale → Provo leg attributed to that tail on 10 September 2025. A pattern that predates the thing it is supposed to explain is a weaker pattern, and that is the honest reading.

The Internet Archive, re-queried properly

The first Wayback survey on this site was run with collapse=digest. That makes every count a distinct-content floor rather than a total, and it makes the one test that matters — did this page stop changing? — impossible by construction. Three of the queries had also failed outright with HTTP 504 and were written down as "snapshots": 0.

One of those three was globe.adsbexchange.com/?icao=0101d3, which is SU-BTT — the most load-bearing aircraft in the case, recorded as never archived because a query timed out.

Re-run without collapse and with retries on 24 August 2026: 30 of 30 queries succeeded, 0 failed.

  • SU-BTT's ADS-B Exchange page has 3 snapshots, 1 September to 17 December 2022. The earlier "never archived" was a failed query, not an absence. A page this site described as unarchived was archived; we simply had not asked successfully.
  • 19 snapshots across 9 URLs. 21 URLs were genuinely never archived — the query succeeded and came back empty. Absence of archival interest is not suppression. Nobody ever asked the Archive to crawl those pages, and there is no mechanism by which not crawling a page is somebody removing it.
  • Every CDX row on every URL is statuscode=200. There is no 200→404 transition anywhere in this dataset. Any page on this site claiming one is wrong.
  • SU-BTT has zero archived snapshots on FlightRadar24, FlightAware, RadarBox and Planespotters. The one aircraft the case turns on is the one with almost no page archive at all. That is a gap in what we can check, not a finding about anybody's conduct.
  • The ADS-B Exchange globe snapshots are empty JavaScript shells, and must not be cited as evidence. Digest AJQHJML54QE6X2IE4TMCM24E3DPGKFD6 is byte-identical across SU-BGM, SU-BTV and SU-BTU, and U743ARQOTM724WNPQLSMSX7TSTHW3FYE across SU-BND and T7-ELL. Identical bytes for different ICAO hex codes means the Archive captured the application frame, not any aircraft's data.

The report is at site/docs/Planes/following/apis/public_open_source/data/wayback/cdx_report.json, and every pull keeps its predecessor beside it with the retrieval timestamp in the filename.

The gaps that turned out to be retention, not removal

This site has published that a band of dates — 12 October to roughly 15 December 2025 — returns HTTP 403 from adsb.lol for every aircraft, and that the free archive therefore cannot check the claim that SU-BTT was photographed on the Sharm el-Sheikh tarmac on 13 October 2025.

That is no longer true, and this page retracts it. Those days are recoverable, from two separate places, and we have them.

First, the map of the archive itself — corrected

The band was described wrongly here and in this repo's own working notes, which said adsb.lol was "normal again by 2025-12-31". It is not. A basket of nine airframes — four from this case, five unrelated controls — was probed date by date on 24 August 2026, and the picture is this:

Windowadsb.lolglobe.airplanes.liveReading
… through 2025-10-11serves normallyserves from about Nov 2023normal
2025-10-12 → about 2025-12-30403 for every aircraft, controls includedserves normallysite-wide
about 2025-12-31 → about 2026-08-01404 for every aircraft, controls includedserves normallysite-wide
from about 2026-08-02serves normallyserves normallynormal

Two corrections come out of that. The 403 band begins exactly at 2025-10-12 — every aircraft in the basket is served on 11 October and none on 12 October. And the 403 band does not end in December; it is followed straight away by a roughly seven-month 404 stretch, with normal service resuming about 2 August 2026. 2025-12-31, the date this repo had recorded as the return to normal, returns 404 for every control.

Neither condition is about this case, and neither may ever be reported as scrubbing. A hard boundary that lands on the same date for a Ryanair 737 and a Lufthansa A380 is an archive changing its mind about a date range. It is also the reason a second network matters, which is the next section.

Backup one: adsb.lol publishes its own archive to GitHub

adsb.lol mirrors its entire historical database to public GitHub releases — one release per day, roughly 3 GB each, under the Open Database License. Every single date in the 403 band is present:

v2025.10.09 · v2025.10.10 · v2025.10.11 · v2025.10.12 · v2025.10.13 · v2025.10.14v2025.10.31 — all present, 3.1–3.8 GB each

So the live API refusing those dates is a serving condition, not a deletion. The organisation that runs the API publishes the same days, in full, on a different platform, under an open licence.

Backup two: an independent volunteer network

globe.airplanes.live runs the same historical trace format as adsb.lol, free, with no account, fed by a different volunteer network. It serves the entire 403 band, and it holds substantially more data per day than adsb.lol does — commonly five to ten times the byte count for the same aircraft on the same date.

The two backups agree

For N102DZ on 13 October 2025 — a date adsb.lol refuses with HTTP 403 — both recovery routes were run independently and compared:

adsb.lol GitHub backup (ODbL)globe.airplanes.live
Registration / typeN102DZ / GLF5N102DZ / GLF5
First seen2025-10-13 16:13:17 UTC2025-10-13 16:13:17 UTC
First position33.6193, −111.9170 (Scottsdale)33.6193, −111.9170 (Scottsdale)
Last seen20:31:07 UTC20:32:20 UTC
Last position38.9692, −77.4567 (Washington Dulles)38.9682, −77.4543 (Washington Dulles)
Trace points1,3231,886

Identical to the second on first contact, and to four decimal places on position, from two archives that do not share a feeder network. That is what a good recovery looks like, and it is the standard the rest of this page is held to.

How much the second network actually recovered — and the control result inside it

Twelve aircraft were run across the three windows this case cares about, day by day, against both archives:

Aircraft-days
Both archives hold the day89
Recovered only from the backup network (globe.airplanes.live)152
Held only by adsb.lol0
Neither archive holds anything563

Lead with the control result, because it is the one that answers the question people actually have. For 1–16 September 2025 — the fortnight this entire case turns on — 74 days are held by BOTH archives and exactly 1 is backup-only. Two independent volunteer networks, with different feeders and different antennas, agree almost completely across the critical window. There is no scrubbing in that fortnight. If data had been pulled from one of them, this is precisely where the two would diverge, and they do not.

The other two windows behave exactly as the archive map above predicts:

  • 8–16 October 2025 — every date on or before 11 October is held by both; every date from 12 October is backup-only. 25 aircraft-days recovered. The 403 band is fully navigable through the second network.
  • 25 April – 5 June 2026126 backup-only, 0 both. adsb.lol holds nothing at all in the 404 stretch, and every day in that window came from globe.airplanes.live.

The honest frame, and it is the counterargument to our own number. A day one network has and the other does not is ordinary. Volunteer ADS-B networks have different feeders in different places; disagreement about a single aircraft-day is the normal condition and means nothing on its own. It becomes a finding only in the two cases seen here — when the gap is archive-wide across unrelated control aircraft, or when a page that was public stops being public. Neither of those is about an airframe. The 152 is a measure of how much a second source is worth, not a measure of how much somebody deleted.

And it produced the first primary data on the Sharm el-Sheikh claim

This site has published that the 403 band "happens to cover the dates a tracker claims SU-BTT was photographed on the Sharm el-Sheikh tarmac — which means the free archive cannot check that claim either way."

It can now, partially, and here is what it shows. Two routes were run for SU-BTT on 13 October 2025:

  • The adsb.lol GitHub backup for that day — the main prod release — was downloaded in full, all 3.3 GB, and filtered. SU-BTT is not in it. adsb.lol's ADS-B feeders recorded nothing from that airframe that day. (adsb.lol also publishes a much smaller companion release per day for MLAT-only aircraft. We attempted it and could not confirm the download completed, so this statement covers the main archive only.)
  • globe.airplanes.live has a fragment: eleven points, spanning 108 seconds, from 18:17:30 to 18:19:18 UTC.

That fragment puts SU-BTT at 22,000 feet over the Gulf of Suez, tracking northwest:

First point18:17:30 UTC — 28.9877 N, 33.0263 E, 22,000 ft
Last point18:19:18 UTC — 29.1244 N, 32.7939 E, 21,350 ft
Track heading304°
Bearing Sharm el-Sheikh → Cairo310°
Position along that route175 km from Sharm el-Sheikh, 200 km from Cairo — roughly midway
Offset from the direct Sharm-to-Cairo track4.5 km and 0.5 km

The aircraft was in cruise, in the right corridor, on the right day, pointing the right way, all but exactly on the great-circle line between Sharm el-Sheikh and Cairo. That is the first primary ADS-B data this investigation has held that bears on the claim at all.

Now the limits, and they are severe. Eleven points over 108 seconds is a fragment — it catches the aircraft in the air and nothing else. It does not establish where the flight departed from. Any traffic already established on that busy corridor looks identical whether it lifted off at Sharm el-Sheikh, somewhere else in Sinai, or from the Red Sea coast. And it says nothing whatsoever about the actual assertion, which was about an aircraft parked on a tarmac next to Air Force One — a photograph of a stationary aeroplane cannot be confirmed or refuted by a cruise-altitude track.

So: consistent with, not evidence of. The movement claim survives contact with primary data for the first time. The tarmac claim is untouched by it, and remains a photograph somebody posted.

Reaching 2022 for the first time

Both free daily archives begin in 2023. The following-planes claim is dated from 2022, and this site has published that those 2022 rows "cannot be tested for free at all" and rest on somebody's screenshot.

ADS-B Exchange closes part of that gap. Its historical API is paid and returns 403 to the public, but it publishes a free sample archive — one complete day per month, the 1st — going back to July 2016. It is one day in thirty, so it can never test a claim about the 13th of anything. It can establish that an airframe existed, flew, and was being received in a month no other free source reaches.

Running it across the fleet retrieved 207 full-day traces spanning 15 aircraft, 35 of them before March 2023 — dates neither daily archive can reach at all. 34 of those aircraft-days fall before 2023 outright, across twelve tails.

The wall this site published is down. The statement carried here and in this repo's working notes — "the archive does not reach 2022; every 2022 claim rests on a screenshot"is no longer true, and this is the retraction. There is now primary position data for 2022, free, with no account and no key, and every trace below self-identifies its own registration inside the file.

Read the sampling caveat first, and carry it every single time these are quoted. This is one day per month, the 1st. Two of the three sampled 2022 days put SU-BTT in the United States — but three sampled days cannot support a rate. These traces establish that the aircraft was in the United States in 2022. They say nothing about how often, and they can never test a claim about the 13th of anything.

Ground-verified 2022 positions

Resolved to the nearest airport in the OurAirports public-domain gazetteer, with the distance published because nearest-airport resolution is geometry, not a landing record:

DateAircraftWhat the trace shows
2022-06-01SU-BTTOn the ground at Wilmington, Delaware (KILG, 0.72 km) at 11:31:13 UTC, then flies to Almaza Air Force Base, Cairo (HEAZ, 1.38 km). 1,508 points.
2022-09-01SU-BTTParis–Le Bourget → on the ground at Wichita, Kansas (KICT, 0.69 km) at 16:33:26 UTC. 1,337 points.
2022-12-01SU-BTUParis–Le Bourget → Spirit of St. Louis, Missouri (KSUS), on final approach at 150 ft, 18:40:48 UTC. 1,245 points.
2022-09-01SU-BND41,000 ft over Bremen, Indiana at 00:00:18 UTC, crossing the United States eastbound, then on the ground at Le Bourget 09:30 UTC. 989 points.
2022-05-01SU-BTTEgypt only — Gebel El Basur ↔ Quesna.
2022-10-01SU-BTVEgypt only — Almaza AFB round trip.
2022-01-01SU-BNDEgypt only — New Cairo ↔ Ras Sedr.

Three of the five claimed clustering states now have primary position data behind them. This site carries a clustering claim — overlaps concentrated in Missouri, Delaware, Utah, Nebraska and Kansas — marked unverified. Delaware (SU-BTT on the ground at Wilmington), Kansas (SU-BTT on the ground at Wichita) and Missouri (SU-BTU into St. Louis) are corroborated by 2022 position data for the first time. Utah and Nebraska are not, on these samples.

And one detail cuts against the fleet's own description. On 1 June 2022 SU-BTT's destination resolves to Almaza Air Force Base, an Egyptian military field, not Cairo International. That is worth stating plainly and worth stating as exactly what it is: a state aircraft using a state airfield, which is ordinary for a government fleet and is not by itself evidence of anything.

None of this puts a Kirk anywhere. It locates aircraft in 2022. The clustering claim is about overlaps, and the other half of every overlap — where Charlie or Erika Kirk actually was — is untouched by position data and remains the weakest part of the whole angle. Erika Kirk's flight logs are reported erased; see Erika Flight Logs Erased.

The wider set, 2022 through 2024

The legs below, including the ones already published here, are the fuller set:

AircraftDateWhat the recovered trace shows
SU-BTT2022-06-01Departs Wilmington New Castle, Delaware 11:31 UTC → Cairo 22:31 UTC. 1,508 points.
SU-BTT2022-09-01Departs Paris Le Bourget 07:04 UTC → Wichita, Kansas 16:59 UTC. 1,337 points.
SU-BND2022-09-01Starts over northern Indiana 00:00 UTC → Paris Le Bourget 09:37 UTC. 989 points.
SU-BTU2022-12-01Departs Paris Le Bourget 09:03 UTC → St. Louis, Missouri 18:40 UTC. 1,245 points.
SU-BTU2023-05-01Paris Le BourgetSt. Louis, Missouri. 1,882 points.
SU-BTU2024-12-01Lincoln, Nebraska 14:13 UTC → Wilmington, Delaware 16:28 UTC. 894 points.
SU-BTT2023-04-01Paris Le BourgetSt. Louis, Missouri 16:01 UTC. 1,166 points.
SU-BTV2022-10-01Local, Cairo. 269 points.

Wilmington, Wichita, St. Louis and Lincoln are four of the cities the overlap spreadsheet names, and the recovered traces push the documented record of these airframes substantially earlier than this site previously carried it — SU-BND by roughly eight months, SU-BTU by about two years, SU-BTV by more than two.

The finding that cuts the other way

The same sweep produced a result that weakens part of the fleet claim, and it is reported here for that reason.

T7-ELL has been carried on this site as a tail with no published legs at all — named in a fleet-list thread, grouped with the "Egyptian armada", never sourced to a single flight. It now has twelve recovered traces, and they do not look Egyptian in the slightest:

Van Nuys → London Luton · Van Nuys local · Caribbean → Miami · Dubai → Kuala Lumpur · Zurich → Abu Dhabi · Dubai → Wilmington · Dubai → Lapland · Dubai → Ethiopia · Dubai → Morocco · Ireland → Dubai

That is a Dubai- and Van-Nuys-based long-range charter aircraft flying a global pattern, which matches its San Marino registration and its community-database operator entry far better than it matches an Egyptian government fleet. The tail should not be grouped with the SU- aircraft, and the one Wilmington arrival in the set (1 October 2025, inbound from Dubai) is a single leg on an aircraft that flies everywhere — not a pattern.

This is what recovered data is for. It closed a gap by removing a claim rather than supporting one.

Read that carefully, because it is easy to over-read. It establishes that the aircraft went to those places. It does not establish that anyone was following anybody. The recurring finding of this investigation's own audit is that the individual flight legs verify at a high rate while the overlap pairings built on them do not — the movements are largely real, and the claim that the movements constitute shadowing is where the sheet falls apart. Nothing recovered here changes that. A trace showing SU-BTT at Wichita on 1 September 2022 says nothing at all about where Charlie or Erika Kirk was that day, and this repo still holds almost no sourced Erika locations for that entire window.

A fifth free source, found while running the sweep

FlightAware refuses nothing. Where FlightRadar24, RadarBox and Planespotters block scripted requests, flightaware.com serves them HTTP 200 — and its per-aircraft page ships a server-rendered JSON blob, trackpollBootstrap, carrying an activity log with named airports and actual takeoff and landing times. No key, no account.

It is not a recovery route. The free log reaches back about a week, the same as everyone else's free tier. What it is worth is that it names fields instead of handing us coordinates to resolve, and it is independent of the ADS-B archives. Run across the fleet on 24 August 2026 it returned 169 legs across nine aircraft, and two of them are worth reporting here.

N1098L and N2100L are operating out of Army airfields, this month

The two LASAI Aviation II Global Expresses returned 37 legs each in a single week. Counting every field either end of every leg:

N1098L — 10–17 Aug 2026N2100L — 10–24 Aug 2026
Biggs AAF (Fort Bliss)25Robert Gray AAF (Fort Hood)27
Amarillo Intl10Biggs AAF (Fort Bliss)17
March ARB7El Paso Intl4
Robert Gray AAF (Fort Hood)5Amarillo Intl4
Lubbock4Garden City3
Sierra Vista Municipal3Roswell Air Center2

Three of those fields are US Army airfields — Biggs at Fort Bliss, Robert Gray at Fort Hood, and March Air Reserve Base — and the aircraft are flying almost nothing else.

Sierra Vista Municipal is the civil half of Libby Army Airfield, on Fort Huachuca. This site has carried the Fort Huachuca link as "an unverified OSINT claim, not a documented tasking record". It is still not a tasking record and it says nothing about September 2025. But it is no longer unsourced: N1098L flew into Fort Huachuca's field three times in one week in August 2026, and the record is a free, third-party, timestamped one that anybody can pull.

Read the limits. This is current activity, not the day of the assassination. Basing an aircraft at an Army field is exactly what an Army-contracted aircraft does and is not itself remarkable — it is the confirmation of which fields that is worth having. And an activity log is a tracking site's summary of flights, not a mission record; who was aboard and what the aircraft was tasked to do remain outside every source on this page.

The five free routes, side by side

RouteCostReachesWhat it recoversLimitation
globe.airplanes.live globe_historyfree, no account2023 → todayFull daily traces. 5–10× the byte count of adsb.lol.Independent network, so it has its own coverage holes.
adsb.lol GitHub releases (ODbL)free2023 → todayThe complete day, including days the live API refuses.~3 GB per day; must be streamed and filtered.
samples.adsbexchange.comfree2016 → todayFull days, one per month. The only free route into 2022.One day in thirty. Cannot test a specific mid-month date.
Internet Archive (Wayback)freewhenever a crawler visitedThe tracking-site page — the flight-history table as published.Sparse and unpredictable. N102DZ has exactly two snapshots in four years.
FlightAware activity logfree, no accountabout a week backNamed airports and actual off/on times, server-rendered so a script can read it.One week. Useless for anything historical.

The last one is the only route that recovers what a tracking site said, as opposed to what the sensors heard. That makes it the only route that can document a removal at all — and it is the flimsiest of the four, because it depends on whether a crawler happened to visit.

What is still gone, and what we still cannot do

The honest list, and it is the most useful section here.

  • Erika Kirk's own itinerary is still absent, and no backup fixes it. Every recovery on this page is about aircraft, and an aircraft track never establishes who was aboard. The 73-overlap tally is measured against a set of Erika Kirk locations this repo cannot reproduce and no tracker has published as a dated list. That gap is the weakest point in the whole aircraft angle and none of this work closed it. See Erika Flight Logs Erased.
  • 2022 is only reachable twelve days a year. Any 2022 claim about a specific date that is not the 1st of a month is still untestable for free.
  • Neither free daily archive reaches before roughly March 2023. The ADSBX monthly sample is the only thing older, and it is thin.
  • FlightRadar24's own multi-year history is behind a paywall and stays there. The page is public; the history is not free. Two Wayback snapshots in four years is everything the archive caught, and the free FR24 page only ever displayed seven days — the archived copy says so at the bottom of the table — so even a perfect capture would never have held the multi-year record the overlap spreadsheet was built from. A Silver subscription (90 days) or Business (3 years) would reach further back than anything on this page. We have not bought one, and that, not a removal, is the reason the FR24 record here stops where it does.
  • Absence still is not evidence. A 404 from a volunteer network means the network heard nothing. It does not mean the aircraft did not fly, and it does not mean a transponder was switched off. The ordinary explanations — parked and silent, outside receiver coverage, or a claimed date that was simply wrong — come first every time.
  • We cannot see intent. Not at FlightRadar24, not anywhere. This page documents what changed and when. It does not tell you why, and nobody should read it as though it did.
  • Our scripted method cannot test a FlightRadar24 removal at all. It gets 403 for the front page. Every statement this page makes about an FR24 page being present rests on the Pass 4 browser capture, not on the script, and the browser pass has been run once, on one day.
  • A confirmed aircraft is still not a confirmed overlap. Twenty-four claimed pairings now have the aircraft where the claim said it was. Not one of them establishes that a Kirk was there.
  • Twenty-one pages of the fleet were never archived at all, and SU-BTT — the aircraft the case turns on — has zero archived snapshots on FlightRadar24, FlightAware, RadarBox and Planespotters. Nothing can be recovered from a page nobody ever crawled.

Counterpoints

  • Blocking a tail number is ordinary and lawful, and it did not happen here. Private aircraft owners routinely request removal from public tracking through the FAA's LADD programme and the trackers' own block lists. Had that been done to N102DZ the page would say so or the aircraft would be absent. Instead every one of the sixteen aircraft loads normally, with a full identity block — so this ordinary explanation is not needed, because there is nothing left to explain.
  • A 403 is not a deletion. Every tracking-data "erasure" examined here dissolved the moment it was tested against control aircraft — including the one this page itself had called a documented removal, and including the N888KG capture sequence this page found for itself and then lost. The lesson is about method, not about anybody's motives: ask an unrelated aircraft, and then a home page, the same question before you conclude anything about this one.
  • A zero can be your own bug. Thirty-nine provenance records here read 0 or null and meant "nobody parsed this", not "nothing was there". A zero is the exact shape a scrub is supposed to leave, which is why it has to be checked before it is published.
  • An empty API response means the API had nothing. It does not mean the aircraft was hidden. Only a track putting the aircraft somewhere else refutes a claim; silence refutes nothing, and cannot support anything either.
  • The recovered data mostly makes the case less dramatic, not more. The record was not destroyed. The flights are ordinary point-to-point business-jet legs. One suggestive detail this site had published turned out to be a misread column.
  • Recovering a trace proves presence, never purpose. Every aircraft on this page has an innocent explanation available — maintenance at a Falcon or Gulfstream shop, diplomatic travel, hub-and-spoke routing — and those explanations are documented elsewhere on this site alongside the claims.
  • None of this is in the criminal case. No flight record of any kind features in the prosecution of Tyler Robinson, who is charged and not convicted. The aircraft strand runs entirely outside it.

Reproduce every line of this page

Nothing here needs an account, a key or a payment. That is the point — a reader who does not believe a word of this should be able to run it and get the same answer.

# the two-archive comparison, per aircraft, per date
# (this is what produced the 89 both / 152 backup-only / 0 adsb.lol-only split)
node recover_erased.js --tail N102DZ

# the free monthly sample archive, back to 2016 - the only free route into 2022
node recover_adsbx_samples.js --tail SU-BTT --from 2022-01 --to 2026-08

# re-extract the flight rows from every archived tracking page on disk
# (this is the script that turned 39 sidecars reading 0 or null into 153 flight legs)
python3 extract_wayback_flights.py

# ask the Internet Archive what it holds, without collapse=digest, with retries
# (30 of 30 queries succeed; three earlier HTTP 504s had been logged as "0 snapshots")
node wayback.js

# test all 85 claimed overlaps against both archives, nearest airport, 15 km radius
node verify_overlaps.js

# rebuild the per-aircraft provenance record the fleet table above is drawn from
node build_tail_provenance.js

# one day from the adsb.lol GitHub backup, filtered to one airframe
curl -sL <release>.tar.aa <release>.tar.ab | tar -xf - --include '*trace_full_a00c85.json'

The code is in site/docs/Planes/following/apis/public_open_source/code/. Every recovered payload is saved under the aircraft's own directory at Planes/<tail>/data/recovered/, with the source in the filename and a .meta.json beside it recording the exact URL, HTTP status, byte count and UTC retrieval time. Nothing overwrites a previous pull — a re-pull lands beside the first with a timestamp, because the diff between two pulls is how a disappearance gets shown.

Each aircraft directory also carries _RECOVERED_DATA.md: the day-by-day table of which archive held what, and which days were recovered from a backup after the primary archive returned nothing.