Developing in two sandboxes and both of them when I attempt to deploy anything via metadata or tooling API the deployment is stuck in a pending status from 5-60+ minutes.

I have a case open for one sandbox but am now seeing it on cs19.

Curious if anyone else is seeing this. SF says they found an issue in their server logs on one instance but I cannot create a case for the second org.

I do not believe it is due to anything on my end as the deployment is sent and stuck in pending.

Oddly enough, saving a class via the UI works but tooling and metadata deploy seems broke.


Response from R&D is that it is working as expected. Deployments from the Metadata API can no longer be expected to be completed in a timely fashion. It could takes up to several hours. Suggestion was to use tooling which cannot create new classes / vf pages in a documented fashion. Basically the way it has been working for the last 8 years can no longer be expected

  • Yep - it's happening to me right now on cs20. Admittedly it's only been 5 minutes so far, but that's longer than normal. Aug 10, 2016 at 23:24
  • It's weird because aside.io save quickly but ide's take forever. Not sure why it would be different. I have set the IDE to both metadata and tooling api with no change
    – Eric
    Aug 10, 2016 at 23:26
  • 1
    yep, happening to me now on cs2 (changeset from PROD to sandbox)
    – cropredy
    Aug 11, 2016 at 1:35
  • 1
    Well, I voted to reopen so you can add this new information as an answer. It probably would be better to include support's verbatim response if possible.
    – Adrian Larson
    Aug 16, 2016 at 20:18
  • 1
    @AdrianLarson - Thanks. I posted the answer with exact quotes. My update was in my own words as interpreted with disappointment. If you feel they should be edited please let me know....Even though that is how I took the conversation lol
    – Eric
    Aug 17, 2016 at 0:36

1 Answer 1


So the response from R&D via Support was:

As discussed on call, I went back to RnD to confirm your request. They have confirmed that It is the nature of multi tenet architecture of Salesforce platform when asyc request is queued, we cannot determine a fair time for the request to go through.

So basically, the delay is working as designed and hour long waits for an IDE to save/deploy a single class is not abnormal despite what we know to be the case.

After pushing the issue on the partner community the answer I received was a little more encouraging yet still vague. At least it has been acknowledged that there IS an issue:

I discussed this with the product team responsible for MD API. They acknowledge that we have been having several issues with MD API based deployments. There are several large deployments being processed (like packages) and since the deployments are transactional, breaking them into batches isn't possible, which causes some deployments to be queued for a longer period. The current situation is not the norm and hopefully will be resolved soon as teams are working on it. The product team also mentioned a strategy which they are working on to alleviate the queuing latency in the next couple of releases.

I have done development using the IDE for a long time so I very well understand everyone's frustration here. Please be assured that the product team is aware of and working on a better solution.

So if you are having issues PLEASE open a case with support even if it gets closed (Or wherever you post your issues) so that if it continues it is known that it is an issue vs just me being crazy :)

As a point of reference - When I posted my case I provided the Deployment ID so at least the logs could be looked into. As other comments suggest there is no pattern. Sometimes it works fin, then so slow for hours, then fine, then 5 minutes later so slow. At least with a deployment ID they can focus the efforts

UPDATE 8-19-2016

Been seeing this on other instances although not to the same degree. Other instances are 5 minutes or so. CS19 seems to be the worst. Update from SF today

For everyone interested. What I'm finding out is that the Deployment jobs are getting demoted within instances. This happens due to a fair usage algorithm that evaluates all messages (jobs) that are executed on the Pods shared MQ system. When demoted, our deployment jobs go from being dequeued from many app servers to only a few, which obviously affects our ability to scale. Once we confirm the behavior, we'll be able to prioritize specific improvements.

  • 1
    multi tenet architecture - I wonder how many tenets they have? Hopefully, poor IDE performance isn't one of them. Thanks for keeping us in the loop.
    – cropredy
    Aug 19, 2016 at 22:02
  • @cropredy - I do not believe it is poor IDE performance as the Deployment makes it to the server. Its just stuck for a LONG time in pending status. IDE is just polling for status at that point.
    – Eric
    Aug 19, 2016 at 22:05
  • right - I misspoke;
    – cropredy
    Aug 19, 2016 at 22:06
  • 2
    while making a lame attempt at humor around tenet v tenant
    – cropredy
    Aug 19, 2016 at 22:12
  • 1
    @cropredy - Ahhhh. I get it now, lol (tenet - a principle or belief, especially one of the main principles of a religion or philosophy) - You should have know with my poor spelling I would not have caught that :)
    – Eric
    Aug 19, 2016 at 22:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .