What is a good delivery latency for news data?

Twitter
Facebook
LinkedIn

Delivery latency in news data is the time between when an article is published and when it arrives in your system. For most professional use cases, under ten minutes is the meaningful threshold. Under seven minutes is where monitoring and risk applications start to gain a genuine time advantage.

“Real-time” is not a useful benchmark on its own. Most providers use the term without defining it, and it obscures significant variation: a feed that delivers English-language tier-one news in under a minute but regional and non-English content in forty minutes is not providing real-time coverage in any operationally meaningful sense.

The number that matters is median delivery time across the languages and regions your use case actually depends on.

Why does latency matter?

For most news consumers, a few hours’ delay is inconsequential. For professional applications, it is not.

Adverse media screening that surfaces a story six hours after it breaks gives a compliance team six hours less to act before the risk is visible to everyone.

Supply chain monitoring that catches a factory closure after the market already knows it has moved from intelligence to history.

Event-driven trading strategies that depend on news signals have no use for a feed that lags behind wire services.

The latency question is therefore a use-case question.
The right answer depends on what your platform does with the data once it arrives. For general research and retrospective analysis, latency is a minor concern. For real-time monitoring, risk alerting, and time-sensitive workflows, it is a procurement criterion.

What determines delivery latency?

Latency in a news feed is the sum of several distinct delays:

  • Discovery time: how quickly the provider identifies that a new article has been published on a given source. Providers that crawl sources on a fixed schedule will always lag behind providers that monitor sources continuously.
  • Indexing time: the time taken to retrieve the article, extract the content, clean it, and attach metadata. The more enrichment you apply at this stage, the longer indexing takes, though a well-engineered pipeline keeps it to seconds.
  • Delivery time: the time taken to route the processed article to your endpoint. Push-based delivery (firehose) is faster than pull-based delivery (polling), because you receive articles as they are indexed rather than waiting for your next request.


The headline latency figure a provider quotes is typically measured from publication to delivery. What it often does not specify is whether that figure covers all sources equally, or whether it reflects performance on a subset of high-priority tier-one outlets with slower handling for regional and non-English sources.

How do you evaluate latency before buying?

Define your latency threshold before starting a trial. Identify the three to five most time-sensitive use cases in your platform, and set a maximum acceptable lag for each. Then test against that threshold specifically.

During evaluation, measure latency by region and language, not as a single average. Ask for median delivery time for the source categories that matter to your use case: local-language business press, regional trade publications, non-English sources. Latency varies most between providers here, and the gap between a headline figure and actual performance tends to be largest.

Cross-reference timestamps: compare the discovery timestamp assigned at indexing against your own system’s receipt time. Do this across a representative sample covering multiple languages and jurisdictions, not just the English-language sources that most providers optimise for first.

What is a realistic benchmark?

Provider claims vary. “Real-time” appears on most vendor pages. Concrete figures are rarer. A feed delivering under ten minutes consistently across all supported languages is performing well. Under seven minutes across the full source base, including non-English and regional outlets, is strong.

Opoint indexes and delivers articles within an average of under seven minutes from publication, across 250,000+ sources in 135 languages and 230 jurisdictions. That figure covers the full source base, not a curated subset of fast-indexed tier-one outlets.

See what coverage looks like for your markets →

Does delivery method affect latency?

Yes, meaningfully. Push delivery, where processed articles are sent to your endpoint as they are indexed, produces lower and more consistent latency than pull delivery, where your system polls the API on a schedule.

For monitoring and alerting use cases, push is the appropriate default. For integration testing, retrospective queries, and bulk retrieval, pull is better suited. Most providers support both; choose based on your latency requirements, not just your engineering preference.

Trusted by

FAQ

Discovery latency is the time between an article being published and the provider detecting it. Delivery latency is the total time from publication to your system receiving the processed article, which includes discovery, indexing, enrichment, and routing. Delivery latency is the operationally relevant figure for procurement decisions.

Yes, and this is one of the most important variables to test during evaluation. Providers typically optimise crawling and indexing for high-volume English-language sources first. Regional, local-language, and non-English sources are often processed more slowly, which means a provider's headline latency figure may not reflect performance on the sources most relevant to your use case.

For real-time monitoring, risk alerting, and event-driven applications, lower latency produces better outcomes.

For retrospective research, historical analysis, and workflows that run on a daily or weekly cycle, latency is a secondary concern and should not drive procurement decisions. Optimise for the requirements of your most time-sensitive use case, not the lowest possible number.

Push delivery sends articles to your endpoint as they are indexed, so latency is determined entirely by the provider's processing speed. Pull delivery requires your system to request new articles on a schedule, which adds the polling interval to whatever the provider's processing time is. For latency-sensitive applications, push delivery is the right default.

Want to see how fast your markets are covered?

Topics and entities document frontpage

Download