38 days of exchangerate.dev performance: freshness and availability

From July 19 through August 26, 2026, a Jakarta-based collector scheduled EUR/USD once per minute against exchangerate.dev. Across 31,614 successful observations, median data age was 30.5 seconds, p95 data age was 57.7 seconds, attempted-request availability was 97.92%, and timestamp, source, and market-session coverage were each 100%.

Measured exchangerate.dev performance

The collector ran from 2026-07-19T02:07Z through 2026-08-26T23:16Z from Jakarta, Indonesia. It used the public, unauthenticated EUR/USD single-pair endpoint with no optional parameters. This is a measured record for one pair, plan, region, and observation window rather than an SLA or a claim about every endpoint.

What this benchmark measures

The benchmark separates API response speed from data freshness. Response latency is the time between starting a request and receiving the complete response. Data age is the time between receiving that response and the provider-reported timestamp for the underlying rate. A fast CDN can return an old rate quickly, so the two measurements must never be merged.

The fixed protocol

• Measure EUR/USD in one direction at the precision each provider returns; do not round before change detection.
• Schedule one request every 60 seconds for at least seven calendar days, including five open-market days.
• Record the provider plan, authentication state, measurement region, parser version, and exact start and end times.
• Use a UTC clock and disclose whether its error was independently calibrated. For this version 1.1 run, it was not; data age uses the recorded response receive time without a measured clock-offset bound.
• Retain every scheduled observation, including HTTP errors, parse errors, missing timestamps, and timeouts.
• Do not publish a provider result until it contains at least 500 successful observations.
• Stay within each provider’s documented rate limits and terms; a provider is not eligible when measurement is not permitted.

The observation record

Store the raw rate and provider timestamp before computing summaries. The normalized record below is sufficient to reproduce each metric while preserving errors instead of silently dropping them.

{
  "provider": "example",
  "plan": "free",
  "pair": "EUR/USD",
  "request_started_at": "2026-07-16T09:00:00.000Z",
  "response_received_at": "2026-07-16T09:00:00.184Z",
  "http_status": 200,
  "rate": "1.16427",
  "provider_data_updated_at": "2026-07-16T08:59:31Z",
  "provider_source_label": "live",
  "provider_market_session_label": "open",
  "response_latency_ms": 184,
  "error_class": null
}

The timestamp rule

A provider is scorable for data age only when it exposes a parseable timestamp that describes the underlying rate. An HTTP Date header or the collector’s receive time does not qualify. If timestamp semantics are ambiguous, report timestamp coverage and mark data age unscored rather than inventing precision.

Version 1.1 calculates data age by directly subtracting every successful, parseable provider timestamp from the response receive time. The collector did not record provider timestamp precision, apply a future-timestamp tolerance, or separately count future timestamps, so those safeguards cannot be claimed for this result. Its clock-calibration limitation is disclosed in the machine-readable report; a future run requiring those controls needs a new collector version.

The weekend rule

Interbank FX closes from Friday 17:00 New York through Sunday 17:00 New York. A provider may legitimately carry its final trading-week value, but the benchmark records whether it labels that condition. The New York boundary is converted for daylight saving time so Sunday reopening is not misclassified as weekend trading. A changing crypto-derived proxy, a carried FX observation, and a daily reference fix are different products; the report must preserve the provider’s source and market-state metadata instead of calling all three “live.”

The publication gate

Every published result must include the scheduled sample count, attempted count, success count, collector coverage, provider availability, p50 and p95 data age, p50 and p95 observed change interval, timestamp coverage, source-label coverage, observation window, measurement region, plan, parser version, and exclusions. Raw normalized observations should accompany the summary wherever provider terms allow redistribution.

Machine-readable protocol

Download the versioned benchmark protocol. It defines eligibility, recorded fields, formulas, required disclosures, prohibited claims, and the current result status. The broader FX data methodology defines exchangerate.dev’s own source and timestamp semantics.