SECOND MEASUREMENT SM-022
conda-forge’s documentation says a new package can be installed “around 15 minutes” after upload. In a week, 624 of 634 single-file packages took longer just to be listed by the CDN’s sync, median 36 minutes, and none reached the index conda reads in under 28
The claim: conda-forge availability: the docs say “around 15 minutes” after upload; in a week, 624 of 634 single-file versions took longer just to be listed by the CDN’s sync, median 36 minutes
What we found: 634 single-file versions uploaded 17–24 Oct: median 36 minutes from upload to the sync that listed them, 624 (98.4%) over 15, 27 over an hour, longest 136. Syncs a median 38.4 minutes apart. None reached the repodata conda reads in under 28 minutes (317 timed, median 49).
Status: Published 31 Oct; checked against the exhibits before publication; advance copy sent to conda-forge (Matthew Becker) 24 Oct
conda-forge is the community library most scientific Python users install packages from. A maintainer’s build uploads the new version to anaconda.org, and users’ conda install reads it from a content delivery network (CDN) that Anaconda copies the channel to in periodic syncs. conda-forge’s documentation gives the time this takes in four places: “around 15 minutes” twice, “ideally around 15 minutes” with longer delays “possible” once, and “about 10 minutes” in its FAQ. For a week we timed every new package version from the upload time anaconda.org records to the CDN sync that first listed it. Of the 634 versions with a single file, 624 (98.4%) took more than 15 minutes, median 36, and none less than 13. Measured to the moment the index conda install reads was updated, none of 317 took under 28 minutes; the median was 49.
- conda-forge’s documentation, read 24 October 2026. The life-cycle page: “The CDN network is synced with the channels periodically. As a result, packages take around 15 minutes to be available for installation after their publication.” The same page, further down: “Validation and CDN sync usually take around 15 minutes after the CI is passing on
main.” The infrastructure page: “Once uploaded to anaconda.org/conda-forge … This step should ideally take around 15 minutes. In some circumstances, longer delays are possible. Check conda-forge.org/status in case of doubt.” The maintainer FAQ: packages show up on anaconda.org “about 10 minutes before they are downloadable via conda”.1 The first and last are not hedged. - Every 3 minutes from 17 to 24 October we read the CDN’s
rss.xml, which lists recently added versions and carries the sync’s timestamp (lastBuildDate), and looked up each new version’s upload time on anaconda.org. 634 versions with one file: median 36 minutes from upload to the timestamp of the sync that listed them; 624 (98.4%) over 15 minutes, 10 at 15 or under, none under 13; 27 over an hour; longest 136. Versions with several files, one per platform, are timed from their last file and look faster (783, median 28), because the sync that lists a version can be one that carries only its earlier files. - Syncs carry a new timestamp a median 38.4 minutes apart, never closer than 33 in the week. A version uploaded in the 15 minutes before a timestamp almost never makes that sync: 10 of 255 single-file versions did. 271 of the 634 missed one sync entirely and were listed by the next. Six times the timestamp did not change for over an hour, the longest 129 minutes on 19 October; in two of the three we could check, no platform’s repodata changed for 74 and 92 minutes either.
- Each sync’s files are written after its timestamp: each platform’s
repodata.json, the indexconda installreads, changed a median 13 minutes after it, and the feed itself 18 to 26 minutes after it, in every one of 234 syncs. Measured to the repodata change, 317 single-file versions from 21 October: median 49 minutes, none under 28. - conda-forge has said the sync slowed. conda/infrastructure issue 1280, opened on 28 January 2026 by Matthew R. Becker of conda-forge core: “conda-forge CDN cloning times have increased to ~30-40 minutes. They were closer to ~10-15 minutes in the past.” Two days later another maintainer saw times over an hour, and a reply said: “We’ve got an internal issue going as well to investigate the root cause and any performance improvements.” The issue is open, with nothing since. What we add is a week of per-package waits nine months later; the documentation’s numbers have not changed.2
- A second path for the start of each wait: for 60 randomly chosen versions we looked for the feedstock’s CI run on
main. 38 matched a run; in 37 of them anaconda.org’s upload time is 3 to 69 seconds before the run finished (check_start_2026-10-24.json). For those 38 the median wait from the CI run’s end, the start the life-cycle page names, is 35 minutes.
Disclosure: Markovian Protocol holds no financial position in Anaconda, was paid by no one for this work, and showed it to no one before publication except Matthew R. Becker of conda-forge core, who opened issue 1280; we sent him a copy on 24 October, seven days before publication. How we work.
Day by day
| Sync timestamp (UTC) | Single-file versions | Median wait | Over 15 minutes |
|---|---|---|---|
| Sat 17 Oct (from 18:16) | 23 | 38 min | 91.3% |
| Sun 18 Oct | 49 | 30 min | 95.9% |
| Mon 19 Oct | 75 | 39 min | 97.3% |
| Tue 20 Oct | 137 | 34 min | 99.3% |
| Wed 21 Oct | 135 | 34 min | 100% |
| Thu 22 Oct | 102 | 41 min | 100% |
| Fri 23 Oct | 103 | 39 min | 98.1% |
| Sat 24 Oct (to 04:04) | 10 | 50 min | 90.0% |
| All | 634 | 36 min | 98.4% |
| Recheck, 25–31 Oct (21 left out after polling gaps) | 662 | 37 min | 99.2% |
Wait = the lastBuildDate of the first rss.xml that lists the version, minus the anaconda.org upload_time (main label) of its file. The first poll, at 18:24 UTC on 17 October, listed 100 versions of unknown age and is left out; so is one version whose files were relabelled from September 2025. 611 of the 634 are noarch (built once for every platform); the 23 single-platform ones had a median of 41 minutes. Quartiles for the 634: 27 and 47 minutes; 90th percentile 54. All 1,417 versions, timed from their last file: median 32 minutes, 89.6% over 15.
Where the time goes
| Step | Median | Middle half | Measured over |
|---|---|---|---|
| Upload on anaconda.org → timestamp of the sync that lists it | 36 min | 27–47 min | 634 single-file versions, 17–24 Oct |
Timestamp → the version’s repodata.json changes | 13 min | 12–21 min | 631 versions, 21–24 Oct |
Timestamp → rss.xml is written | 21 min | 20–22 min | 234 syncs |
| Upload → repodata changed | 49 min | 40–59 min | 317 single-file versions, 21–24 Oct |
| Feed written → our poll, through Cloudflare, sees it | 2.4 min | 1.7–3.2 min | 233 syncs; at most 4.5 |
| Between sync timestamps | 38.4 min | 36.6–40.2 min | 233 intervals |
Repodata changes are from the Last-Modified header of each platform’s repodata.json on conda.anaconda.org, read every 3 minutes from 05:23 UTC on 21 October. A version’s end is the first change at or after its sync’s timestamp, in every platform it was built for. Of 789 versions listed from then on, 631 are counted: 123 were built for a platform we did not read (win-arm64, linux-riscv64, win-32), and 35 were in syncs that followed a stall of over an hour, when repodata can be written before the timestamp (on 23 October two platforms’ repodata was written 17 and 20 minutes before the 04:52 timestamp of the sync it belonged to). The timestamp is the sync’s own; the feed and the repodata are written after it, but its copy of the channel is taken before it, which is why uploads just before it miss it.
Who said what, and when
The CDN’s timing has been discussed in public since 2021, and conda-forge runs a status page that shows the CDN cloning.3 The estimates, in order:
| Dec 2021 | conda/infrastructure discussion 13: “Packages take a long time to become visible to conda search after upload.” |
| 2022 | conda-forge.github.io issue 1735, “Docs out of date regarding CDN time”, opened in April. June: “This week, a change is being pushed that will have the CDN update time at ~8 minutes instead of several hours.” November: “The channel clone job runs every ~2 minutes, and it takes about 6 minutes to complete.” Closed. |
| Apr 2023 | conda/infrastructure issue 740, “CDN sync seems to be slower than usual this week”; in May: “The cron job used to take 6-7 minutes.” |
| Oct 2023 | Issue 829: “Most packages are available through the CDN in 15-20min, but osx often takes much longer, like 1-2h.” Issue 836: packages missing from the CDN two hours after upload. |
| Mar 2024 | Issue 892, “Slow CDN mirroring”; in April: “Approaching the 500min mark.” Closed November 2024. |
| Aug 2024 | The life-cycle page with “around 15 minutes” is added (pull request 2167, 13 August). conda-forge.github.io issue 2272, on new cloning infrastructure, 29 August: “it now takes 13-14 minutes for each run.” |
| Jan 2026 | conda/infrastructure issue 1280: cloning times “increased to ~30-40 minutes”; two days later: “Seeing times over 1h right now.” Open. |
| Oct 2026 | This measurement: sync timestamps 38 minutes apart; single-file versions a median 36 minutes from upload to the sync that lists them, 49 to their repodata. |
Saved copies of every thread, with comments, and the life-cycle page’s commit history, are in sm-022/exhibits/.
Why the wait matters
The documentation is what a maintainer goes by after merging a release: when to expect the package, when to start the next build that depends on it, when to tell users it is out. The FAQ tells users who see a version on anaconda.org that it will be installable in about 10 minutes; from 21 to 24 October the median from upload to repodata was 49. A wait of 30 to 60 minutes breaks nothing on its own. A pipeline that waits 15 minutes for a new dependency would not have found 628 of the 631 versions we could time to repodata.
How this ends
Either side can close it. conda-forge owns the four sentences and can change them to what the sync does now; the infrastructure page already says “ideally” and points to the status page, but the life-cycle page and the FAQ do not. Anaconda runs the sync, and the investigation from January can bring it back near 15 minutes. We keep polling and recheck weekly; the day table gets a new row each week.
Our questions
To be sent to the conda-forge core team and Anaconda’s infrastructure team on conda/infrastructure issue 1280. Answers will be printed here as written.
- Will the life-cycle page’s “around 15 minutes” and the FAQ’s “about 10 minutes” be updated to the current sync, or is a return to about 15 minutes expected, and when?
- What did the investigation from January find, and is there a target for the time between syncs?
- What moment does the
lastBuildDateinrss.xmlmark? The feed and repodata are written after it, and single-file versions uploaded in the 15 minutes before it are almost never in that sync (10 of 255).
Their reply, scored
| 17 Oct 2026 | Polling began. |
| 21 Oct 2026 | A review of prior work found the threads above; per-platform repodata polling added. |
| 24 Oct 2026 | A week measured. An independent check of every number and quote against the exhibits before publication corrected the mechanism: versions with several files are timed from their last file, so the headline is now the single-file versions. Draft; nobody outside has seen it. |
What we can’t be sure of
- One week, from one vantage point. Issue 1280 says clone runs took 10 to 15 minutes before January; we don’t know how many of the months since looked like this week.
- We see versions through
rss.xml. No sync listed more than 28, so the feed’s 100-item limit cut nothing, but a version that never appears in the feed is not counted. - The start is anaconda.org’s
upload_time, which falls seconds before the CI run ends, so it is probably the build’s upload to conda-forge’s staging channel. conda-forge then validates the file and copies it intoconda-forge; we did not time that step. The life-cycle page counts it (its start is the CI passing); the infrastructure page and the FAQ start after it, so against those two our waits may include a step their figures leave out. - The repodata figure rests on
Last-Modifiedheaders and assumes the first change after a sync’s timestamp is the one that carries the version. We checked that for a day, 24 to 25 October, by downloadingnoarch/repodata.jsonat each change and listing what it added (repodata_presence_2026-10-24.jsonl, script cf_presence.py): for all 58 single-file versions it covered, the first write containing the version was the one the headers gave, and none was under 28 minutes from upload. - A maintainer in issue 1280 called the upload time in anaconda.org’s list view wrong; we read the file API, and it agreed with the CI run’s end for 37 of 38 versions to within 70 seconds. The 38th was 12.7 minutes off and its matched run ended after the sync that listed it, so it is probably a different run.
Run it yourself
python3 cf_poll.py # every 3 minutes: rss.xml + anaconda.org upload times -> versions.jsonl, feeds.jsonl python3 cf_subdir_lm.py # every 3 minutes: Last-Modified of each repodata.json -> subdir_lm.jsonl gunzip -k exhibits/*.jsonl.gz python3 -I analyze.py exhibits summary_2026-10-24.json python3 -I check_start.py exhibits/versions.jsonl 60 20261024 check_start.json # needs the GitHub CLI
Standard-library Python 3; the pollers ran from cron on one machine. Scripts and exhibits: sm-022/.
References
- conda-forge documentation: Life cycle of a package (conda-forge.org), Infrastructure, Maintainer FAQ; source at conda-forge/conda-forge.github.io commit e28b9c5 (23 October 2026). Saved copies life_cycle, infrastructure, maintainer_faq, the life-cycle page’s commits.
- conda/infrastructure issue 1280, CDN cloning times increased to 30-40 minutes, 28 January 2026. github.com, saved copy conda_infrastructure_issue_1280_2026-10-24.json; its author’s GitHub profile (“@conda-forge core”), github_user_beckermr_2026-10-24.json.
- conda-forge status page, conda-forge.org/status; conda/infrastructure discussion 13 and issues 740, 829, 836, 892; conda-forge/conda-forge.github.io issues 1735 and 2272. Saved copies in sm-022/exhibits/.
- The CDN:
https://conda.anaconda.org/conda-forge/rss.xmland/<platform>/repodata.json; anaconda.org file API,https://api.anaconda.org/package/conda-forge/<name>/files; GitHub Actions and Azure Pipelines (dev.azure.com/conda-forge/feedstock-builds) run records.