How to apply this guide
Follow a result from the venue to your screen, and learn what an update timestamp really tells you.
Compare the match timestamp with current feed coverage and freshness. The match-status guide explains why a pause does not mean the match has finished.
A result passes through several systems
An event has to be observed, recorded, distributed by a provider, collected by the website and delivered to your browser. Delay at any of those stages affects what you see.
A fast page can still carry delayed data. A slow page can carry an otherwise prompt feed. Performance and data latency are separate qualities and both should be measured.
Polling frequency is not a speed guarantee
A website may check its provider frequently, but repeatedly requesting the same unchanged response cannot make the underlying information newer. Free or entry-level plans may intentionally delay scores.
Our browser refreshes the local results endpoint periodically. The server collects football and racing data on separate schedules appropriate to the configured providers. Those intervals are collection targets, not promises about when an event will appear.
Two times worth distinguishing
The event time describes when something happened or was scheduled. The fetched time describes when our server successfully obtained a record. A provider may also supply its own last-updated time.
A successful fetch does not prove that a record is official or instantaneous. That is why the page also reports feed mode, coverage state and the sporting status.
What happens during an outage
Deleting the last known score during an outage is unhelpful. Presenting it as freshly live is misleading. Results.fast retains the last successful record and adds a stale-data notice when collection falls behind.
If no data has ever been collected for a date, the page says coverage is unavailable. It does not claim there were no fixtures. You can use the data-status page to distinguish an empty response from a disconnected feed.
Distinguish a connection problem from a coverage limit
A request can succeed while returning no records for the selected competition. That is different from a failed request, and neither tells you whether a match actually took place. The account’s coverage, requested date and available data fields all matter.
Troubleshooting starts by identifying which layer has information. If the provider response is current but excludes a competition, repeatedly refreshing the browser will not add it. If collection has failed, a previously displayed score can remain useful provided it is clearly described as the last known record.
Use timestamps for a question they can answer
A collection timestamp tells you when the server received a response. It can help diagnose a stalled collector, but it does not prove when a goal was scored or when a racing verdict became official. A provider’s own modification time is another distinct field.
Avoid comparing timestamp strings without checking the timezone. A UK summer-time display and a UTC value can represent the same instant with different clock readings. Our date filters use Europe/London, while stored collection times use UTC. That separation keeps archive selection consistent through clock changes.
The four layers of an update
| Layer | What can delay it | What the reader can check |
|---|---|---|
| Venue and confirmation | Observation or a review of the outcome. | Sporting status, such as a photo or enquiry. |
| Data provider | Collection, distribution or plan restrictions. | Provider mode and coverage information. |
| Website collector | Network errors, quotas or interrupted jobs. | Last successful collection and stale notice. |
| Browser | Connectivity or a page left open. | Refresh result and the displayed timestamp. |
A fresh fetch of delayed information
Imagine that the server successfully receives a provider response at 15:20, but the subscription supplies scores with an upstream delay. The page can truthfully say the data was collected at 15:20 while still showing an earlier match state. Calling that response “instant” would be inaccurate. This is why results.fast separates a collection time from a delayed-feed label. A successful HTTP request is evidence that transport worked, not proof that the result arrived at the moment of the event.
A practical reading checklist
- Check the selected date and competition.
- Read the feed-mode label.
- Compare the last successful collection with the current time.
- Check event confirmation separately from freshness.
- Avoid interpreting missing coverage as no fixtures.
For unfamiliar terms, use the racing and football glossary alongside the result.
Common questions
Will refreshing every second make a delayed feed live?
No. It can only request the information currently available to the service. A provider-side delay or subscription limit remains in place.
Why retain old results during an outage?
A labelled last-known record is often more useful than a blank page. The important requirement is to avoid presenting that record as newly verified.
Sources and further reference
Examples in this guide explain how to read a record; they are not reports of actual events. Competition-specific rules and the provider’s field definitions take priority for a particular result.