Re-indexing built-in package repository take too long


We have ~6000 packages in our instance, and re-indexing the built-in package repository usually takes ~2 hours.

All deployments are slowed down during this process.

Is there a way to expedite the package indexing process?



Hi Ge,

I have just updated your previous thread with more information, however I will paste the information here as well as the other thread is private.

I’ve had a look at your logs and can see that you have 10,972 packages and that the task ran for 87.5 minutes. That works out to 2.1 packages/second. I’ve checked with an engineer and we are reading the entire contents of the file to retrieve the required meta-data and generate a file hash which we use to compare against the records that we have in Octopus. We don’t have any plans to modify this behaviour at this point in time.

As performance is a concern for you we would recommend [disabling the task]( and only uploading files to the Built In Octopus feed via out [recommended methods](

If you do need to continue uploading packages directly to disk the only recommendation that I have is to ensure that server restarts and/or task syncs are scheduled to occur outside of high usage periods.

Any further questions please let me know,


Hi Alex,

Thanks for looking into this!

One more question, you say that we have 10,972 packages, but on the UI, it shows that we have 5870 packages.

What you see is almost 2 times of what I see. Where can I find the accurate package number?

Hi Ge,

The most obvious conclusion here is that as the sync task ran 9 days prior to the screenshot that your retention policies have cleaned up the packages. One way to check would be to have a look at how many files are actually on disk in your package repository and make sure that they match what Octopus is report.

Any further questions please let me know.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.