From Satellite Scan to Launch Evidence: Which Timestamp Means What?

A feed refreshed a few minutes ago can describe an observation from last week. Before calling a launch signal timely, ask a more specific question: timely relative to which event?

Satellite acquisition, product creation, a recorded detection, public publication, and your own retrieval happen at different points. A useful evidence record keeps those times separate. Where the available sources do not expose a stage, the honest value is unknown.

This guide follows a public record through the timestamps a reader can inspect. The diagram is a conceptual provenance map, not a measured description of LaunchDetect’s internal processing pipeline.

Start with the scene, not the refresh badge

A satellite image represents an acquisition interval. NOAA’s ABI filename guide distinguishes observation start, observation end, and file creation times. It also identifies the product, satellite, scan sector, and mode in the filename.

These details answer different questions. The observation interval locates the measurement in time. The file-creation label concerns production of that data file. A timestamp on a downstream web page concerns that page or its contents, depending on its documented meaning. None should silently substitute for another.

For a scene you intend to analyze, preserve the complete filename and its original header. Record the instrument, product, band, sector, acquisition interval, and units. A cropped picture and a caption may be enough to illustrate a source’s interpretation; they are usually insufficient to reconstruct its timing chain.

Keep the satellite identity attached to the historical scene. NOAA’s current constellation description identifies GOES-19 as GOES East and GOES-18 as GOES West. Older examples can correctly name an earlier spacecraft. Updating the label on an old image to today’s spacecraft would corrupt its provenance.

Draw the stages you can actually support

The arrows show dependencies to investigate. They do not imply that every stage has a public timestamp, that each stage runs only once, or that the time between stages has been measured.

The minimum ledger has four columns: the label, its value, what it means, and where that meaning came from. Preserve original values alongside any normalized UTC representation. If a source gives only a minute, do not invent seconds. If a clock’s precision or synchronization is unknown, record that limitation before comparing systems.

Read a real public snapshot

The latest-detection endpoint was retrieved on October 3, 2026 at 03:11:35.632594 UTC. That captured response described record ld-dbd773dda2e52ceb, labeled Falcon 9 Block 5 | USSF-385. This is a government-mission example of public evidence, with no civilian-mission claim.

The following values belong to that captured response. Opening the live endpoint later can produce different publication fields or a different record.

The API guide defines scheduledT0 as scheduled time, detectedAt as recorded detection time, and generatedAt as publication time. The associated evidence page labels its displayed thermal observation as acquired at 14:01:18 UTC. That page-level label does not supply the original scan interval or every intermediate processing time.

The ledger therefore preserves both what is present and what remains unverified. It does not rename scheduledT0 as an independently measured liftoff time.

Calculate an interval only after naming its endpoints

Two simple subtractions are possible from this capture:

• Feed publication minus recorded detection: 6 days, 13 hours, 6 minutes, 35 seconds.
• Client retrieval completion minus feed publication: approximately 3 minutes, 43 seconds.

The first is the age of the recorded detection at this feed publication. It does not establish how long the detection originally took to publish. A later refresh can republish an older record.

The second is the age of the publication timestamp at this client’s retrieval, subject to clock accuracy. It combines whatever happened between the documented publication time and that read. It is not a measurement of network transit, processing time, or cache residence alone.

A subtraction of detectedAt and scheduledT0 would yield 24 seconds. Those labels still would not establish detection delay after actual liftoff. Arithmetic can be exact while the interpretation is wrong.

For an end-to-end delivery study, agree the endpoints first. You might need a source acquisition interval, a documented first-publication event, and a receiver’s first successful receipt. Retain evidence for each, describe polling intervals, and report missing cases. When first receipt is observed only by periodic polling, the first positive poll provides a bound on availability rather than an exact first-publication instant.

Cadence describes opportunities, not guaranteed delivery

Scan schedules, publishing schedules, and client polling are separate processes. The API guide describes a nominal five-minute publisher and possible additional caching, while also allowing for failures and delays. That documentation is useful for client behavior; it supplies no guaranteed end-to-end delivery time.

Do not infer global completeness from a recent feed either. A rolling, bounded list can help discover available records without defining every launch that should have been observed. The right response to a missing stage is to document the gap and obtain the needed evidence, rather than deriving a performance claim from unrelated timestamps.

A timestamp check you can reuse

Before quoting a time, ask: What happened at this moment? Who assigned the value? Does it refer to an interval or an instant? Has the record been refreshed or corrected? Which endpoints would be needed to support the delay I want to calculate?

Start with an evidence record and the published field definitions. Build the ledger first. It will show which timing questions the public record answers, and which need a more complete source history.