IPFS logo

IPNI - cid.contact

Metrics on the Interplanetary Network Indexer - cid.contact

IPNI metrics on indexer uptime, traffic volume served, as well as performance metrics on lookup and publish performance.

Availability & Traffic Volume

Key activity metrics on indexer uptime and daily requests served

IPNI Uptime per Day

IPNI Uptime per Day

This graph shows the uptime of the InterPlanetary Network Indexer (IPNI) cid.contact.

The legend means the following:

  • Up The IPNI accepted our advertisement announcement and indexed the content within 5 minutes.
  • Delayed Ingest The IPNI accepted our advertisement announcement but did not index the content within 5 minutes.
  • Down The HTTP call to the /announce endpoint failed.
  • Unknown We don't have valid data for this time period.

We consider an Up/Delayed Ingest/Down state to be valid for $index_timeout * $number_probes. In our case, the index timeout is 5 minutes and we have 4 probes, so if we detect a certain state, we consider the IPNI to be in that state for 5 * 4 = 20 minutes. If we probe again after, say, 25 minutes, we have a 5 min gap, which this graph would show as Unknown.

Prior to 2025-10-28, the IPNI calculation was simply calculating the error rate by dividing the number of failed probes by the total number of probes. This could have incurred biases and we consider the new calculation to be more accurate.

Loading ...

IPNI Requests / Day

IPNI Requests / Day

Total number of requests served by the indexer per day.

Loading ...

Lookup Performance

Lookup performance, in terms of latency, to serve cached and uncached content, from several regions.

IPNI Lookup Latency Trend

IPNI Lookup Latency Trend

The graph shows different percentiles of the “Time To First Provider Record” (TTFPR) metrics over time. In order to measure the TTFPR, we start the stopwatch right before we do the https://{ipni}/cid/{cid} HTTP request to the indexer and stop it when we have received and parsed the full record.

    We aggregate these latency measurements on a daily basis and calculate the 50th and 90th percentiles incorporating data
    from multiple regions. In our measurement setup, we do multiple requests for the same CID. To differentiate between cached 
    and uncached latencies, we show the latencies of the first requests for a CID as “uncached” and subsequent request latencies as “cached”.

    It is important to note that the resulting TTFPR percentiles are artificial composites and do not reflect the specific
    performance of any individual region. Rather, it allows to discern general tendencies and fluctuations in TTFPR across the combined dataset.
    By focusing on these overall trends, we can gain valuable insights into the performance of IPNI TTFPR performance as a whole, 
    making it easier to identify any notable deviations or improvements in that metric over time.

    The sample size (right side of y-axis) corresponds to the number of cached retrievals at a specific day summed across all considered regions.
    The number of uncached retrievals is usually exactly the same and therefore not shown separately.

Lookup latency for cached and uncached content at the p50 and p90 percentiles

IPNI Lookup Latency (uncached)

IPNI Lookup Latency (uncached)

The graph displays the latency for the “Time To First Provider Record” (TTFPR) observed from various regions per day. Each line represents the Cumulative Distribution Function (CDF) of the lookup latency in a specific region. Note that the latency on the x-axis is presented in a logarithmic scale. We distinguish between two types of latencies: uncached, which refers to the first request for a CID, and cached, which pertains to subsequent requests for a CID.

Duration of the IPNI lookup operation displayed in seconds for cached and uncached CIDs.

IPNI Lookup Latency (cached)

IPNI Lookup Latency (cached)

The graph displays the latency for the “Time To First Provider Record” (TTFPR) observed from various regions per day. Each line represents the Cumulative Distribution Function (CDF) of the lookup latency in a specific region. Note that the latency on the x-axis is presented in a logarithmic scale. We distinguish between two types of latencies: uncached, which refers to the first request for a CID, and cached, which pertains to subsequent requests for a CID.

Duration of the IPNI lookup operation displayed in seconds for cached and uncached CIDs.

Publish Performance

Publish performance, in terms of latency, to serve cached and uncached content, from several regions.

Time to Index

Time to Index

The graph displays the latency to publish CIDs to IPNI, as observed from various regions per day. Each line represents the Cumulative Distribution Function (CDF) of the latency in a specific region. Note that the latency on the x-axis is presented in a logarithmic scale. We distinguish between two types of latencies: "Time to Index", when the CID has been successfully received by the Indexer and "Time to Availability", when the CID is available to be queried.

Duration of the IPNI publish operation displayed in seconds.

Time to Availability

Time to Availability

The graph displays the latency to publish CIDs to IPNI, as observed from various regions per day. Each line represents the Cumulative Distribution Function (CDF) of the latency in a specific region. Note that the latency on the x-axis is presented in a logarithmic scale. We distinguish between two types of latencies: "Time to Index", when the CID has been successfully received by the Indexer and "Time to Availability", when the CID is available to be queried.

Duration of the IPNI publish operation displayed in seconds.

Performance Comparison

Lookup and Publish performance comparison of IPNI (cached and uncached content) to the IPFS Amino DHT and FullRT

DHT/IPNI Lookup Comparison

Lookup performance comparison between Amino DHT and IPNI for several settings and percentiles

DHT/IPNI Publish Comparison

Publish performance comparison between Amino DHT and IPNI for several settings and percentiles

Related Work

Blog posts, papers and talks by the ProbeLab team about IPFS.

og-libp2p
Blog post

Can libp2p punch through NATs?

How efficient is libp2p’s DCUtR protocol in connecting actual peers directly?

IMC '26 Conference Paper
Paper

Large-Scale Measurement of NAT Traversal for the Decentralized Web: A Case Study of DCUtR in IPFS

The promise of decentralized peer-to-peer (P2P) systems is fundamentally gated by the challenge of Network Address Translation (NAT) traversal, with existing solutions often reintroducing the …

og-ipfs
Blog post

Optimistic Provide: How We Made IPFS Content Publishing 10x Faster

How a statistical approach cut IPFS content publishing times by over one order of magnitude.

IPFS Logo Blog Hero
Blog post

IPFS Gateway Performance Measurements

The ProbeLab team has been busy building new IPFS Gateway performance measurements

From rawpixel.com / Freepik
Blog post

ProbeLab's 2025 Review and 2026 Outlook

What we've achieved in 2025 and what we're targeting in 2026

University Other
Paper

Measuring and Optimizing Peer-to-Peer Networks: A Case Study of the InterPlanetary File System

The Internet's transformation from a decentralized network of networks into a landscape dominated by centralized platforms has created systemic risks including infrastructure fragility, censorship vulnerabilities, …