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.

The index size and provider metrics come from the latest storage scan of cid.contact. An entry is one multihash. A slot is one record of a provider for a multihash, so a multihash with records of two providers has two slots. Deleted entries are multihashes whose records are all gone. Key and value bytes are the size of the stored data.

99,544,583,937
99.5B
Active Entries
Oct. 16, 2026, 9:04 a.m. UTC
Last updated 1 week, 5 days ago
3.2
3.2 TB
Active Key Bytes
Oct. 16, 2026, 9:04 a.m. UTC
Last updated 1 week, 5 days ago
5.6
5.6 TB
Active Value Bytes
Oct. 16, 2026, 9:04 a.m. UTC
Last updated 1 week, 5 days ago
279,871,038,509
279.9B
Active Slots
Oct. 16, 2026, 9:04 a.m. UTC
Last updated 1 week, 5 days ago
12,880,232,751
12.9B
Deleted Entries
Oct. 16, 2026, 9:04 a.m. UTC
Last updated 1 week, 5 days ago
20,173,620,216
20.2B
Deleted Slots
Oct. 16, 2026, 9:04 a.m. UTC
Last updated 1 week, 5 days ago

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 a later step timed out, for example the content was not indexed within 5 minutes.
  • Down Another error happened while we published the content, for example the HTTP call to the /announce endpoint failed.
  • Unknown We don't have valid data for this time period. Measurements in which the IPNI answered 429 Too Many Requests count as measurement errors, so their time also shows as Unknown.

Our Parsec measurement nodes in several regions regularly publish content to the IPNI. When we detect a state, we consider the IPNI to be in that state until the next measurement from the same region, but at most for 15 minutes or for 5 minutes (the index timeout) times the number of regions, whichever is longer. If the next measurement comes later, the time in between shows as Unknown. Each bar shows the share of the day in each state, averaged over all regions. The tooltip shows the number of measurements (samples) of the day.

Before the dashed Changed Calculation line (late October 2025), the chart shows a simpler calculation: the share of our published CIDs with an error (Down) and without an error (Up). This could have incurred biases and we consider the new calculation to be more accurate.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

Loading ...

IPNI Requests / Day

IPNI Requests / Day

Shows the total number of HTTP requests to the cid.contact indexer per day (UTC). The value is the daily sum of the Requests metric of the AWS CloudFront distribution in front of the indexer, so it counts all requests that reached CloudFront, also the ones that CloudFront answered from its cache.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

Loading ...

Index Contents

What cid.contact stores, from its latest storage scan: the providers with the most records, how much of the index the largest providers hold, and how provider sizes spread.

cid.contact Top Providers

cid.contact Top Providers

Shows the providers with the most records in the cid.contact index. Select the metric and the number of providers.

  • Multihashes: the number of distinct multihashes that have at least one record of the provider.
  • Slots: the number of records of the provider. A multihash that the provider advertises under two contexts counts as two slots and one multihash.
  • Deleted contexts: the number of slots of the provider whose context record is gone, while the provider still has other records.

Provider names are hints and are not verified. A name is the Filfox tag of the Filecoin storage provider ID in the provider's address in the IPNI registry, else the hostname of that address. Providers without a name show a short peer ID. Hover a bar to see the full peer ID and the source of the name.

The data comes from cid.contact/metering/providers, the latest storage scan of the indexer. cidstats.ipni.io shows the same data.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

Loading ...

Share of Multihashes Held by Top Providers

Share of Multihashes Held by Top Providers

Shows the share of all provider multihashes in the cid.contact index that the largest 1, 5, 10, 25 and 50 providers hold. The size of a provider is its number of distinct multihashes.

The total is the sum over all providers. A multihash that two providers advertise counts once for each of them, so the total can be larger than the number of active entries in the store.

The data comes from cid.contact/metering/providers, the latest storage scan of the indexer. cidstats.ipni.io shows the same data.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

Loading ...

Providers by Size

Providers by Size

Shows how many providers have how many multihashes in the cid.contact index. Each bar is one power of ten: the bar "1K–10K" counts the providers with at least 1,000 and less than 10,000 distinct multihashes. The first bar also counts the providers that have no multihashes left.

The data comes from cid.contact/metering/providers, the latest storage scan of the indexer. cidstats.ipni.io shows the same data.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

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

Shows the 50th (p50) and 90th (p90) percentiles of the IPNI lookup time in seconds per day at the cid.contact indexer. The lookup time is the "Time To First Provider Record" (TTFPR): we start the stopwatch right before we send the https://{ipni}/cid/{cid} HTTP request to the indexer and stop it when we have received and parsed the full record. The data comes from our Parsec measurement nodes in several regions.

We request each CID more than once from each region. The first request for a CID from a region is uncached, and the second request for the same CID from the same region is cached. Only successful requests count.

Select Composite to calculate the percentiles over the requests from all regions together, or select one region. The composite percentiles do not show the performance of any single region, but they show the general trends and changes of the TTFPR.

The faint bars (right y-axis) show the number of uncached requests per day. The number of cached requests is usually the same and is not shown.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

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

IPNI Lookup Latency (uncached)

IPNI Lookup Latency (uncached)

Shows the distribution (CDF) of the IPNI lookup time in seconds at the cid.contact indexer on the selected day. The lookup time is the "Time To First Provider Record" (TTFPR). There is one line for all regions together (All Regions) and one line per region. The x-axis uses a logarithmic scale and ends at 2 seconds. Use the date picker to select another day.

We request each CID more than once from each region and distinguish two types of lookups: uncached is the first request for a CID from a region, and cached is the second request for the same CID from the same region. Only successful requests count. The data comes from our Parsec measurement nodes.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

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

IPNI Lookup Latency (cached)

IPNI Lookup Latency (cached)

Shows the distribution (CDF) of the IPNI lookup time in seconds at the cid.contact indexer on the selected day. The lookup time is the "Time To First Provider Record" (TTFPR). There is one line for all regions together (All Regions) and one line per region. The x-axis uses a logarithmic scale and ends at 2 seconds. Use the date picker to select another day.

We request each CID more than once from each region and distinguish two types of lookups: uncached is the first request for a CID from a region, and cached is the second request for the same CID from the same region. Only successful requests count. The data comes from our Parsec measurement nodes.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

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

Shows the distribution (CDF) of the time in seconds to publish a CID to the cid.contact indexer on the selected day. There is one line for all regions together (All Regions) and one line per region. The x-axis uses a logarithmic scale. Use the date picker to select another day.

We measure two steps of the publish operation:

  • Time to Index: the time until the indexer has successfully received the CID.
  • Time to Availability: the time until the CID is available for lookups at the indexer.

Only successful publish operations count. The data comes from our Parsec measurement nodes.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

Duration of the IPNI publish operation displayed in seconds.

Time to Availability

Time to Availability

Shows the distribution (CDF) of the time in seconds to publish a CID to the cid.contact indexer on the selected day. There is one line for all regions together (All Regions) and one line per region. The x-axis uses a logarithmic scale. Use the date picker to select another day.

We measure two steps of the publish operation:

  • Time to Index: the time until the indexer has successfully received the CID.
  • Time to Availability: the time until the CID is available for lookups at the indexer.

Only successful publish operations count. The data comes from our Parsec measurement nodes.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

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

DHT/IPNI Lookup Comparison

Compares the lookup time in seconds of the IPFS Amino DHT and of the cid.contact IPNI indexer per region on the selected day. Select P50 or P90 to show that percentile of the lookup times of the day, and use the date picker to select another day.

  • DHT: lookups through the Amino DHT from nodes with the default DHT client.
  • FullRT: lookups through the Amino DHT from nodes with the full routing table DHT client (also known as the accelerated DHT client).
  • IPNI (uncached): the first request for a CID at cid.contact from a region.
  • IPNI (cached): the second request for the same CID from the same region.

The data comes from our Parsec measurement nodes. Only successful lookups count. The tooltip shows the number of samples.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

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

DHT/IPNI Publish Comparison

DHT/IPNI Publish Comparison

Compares the publish time in seconds of the IPFS Amino DHT and of the cid.contact IPNI indexer per region on the selected day. Select P50 or P90 to show that percentile of the publish times of the day, and use the date picker to select another day.

  • DHT: the time to publish a CID to the Amino DHT from nodes with the default DHT client.
  • FullRT: the time to publish a CID to the Amino DHT from nodes with the full routing table DHT client (also known as the accelerated DHT client).
  • IPNI (index): the time until cid.contact has successfully received our CID.
  • IPNI (available): the time until the CID is available for lookups at cid.contact.

The data comes from our Parsec measurement nodes. Only successful operations count. The tooltip shows the number of samples.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

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

Providers

All providers in the latest storage scan of cid.contact. Filter by name or peer ID and sort by any column. Names are hints and are not verified: they come from the Filfox tag of a Filecoin storage provider, else from the hostname of the provider's address in the IPNI registry.

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, …