There are several steps that happen behind the scenes when you kick off a validation or a deployment to a Salesforce org with Gearset:
Gearset builds your deployment package and uploads it to Salesforce.
Salesforce places your package into the queue for processing.
Salesforce runs any tests.
Salesforce checks your package file and containing metadata are valid for deployment.
Salesforce applies your changes to your target org.
Depending on the size of the package and the speed of Salesforce, the time taken for these steps can vary significantly.
What causes the variations in the validation/deployment time?
The load Salesforce is experiencing at the time of your validation or deployment is the primary cause. During peak hours in the US, when the most users are active on the platform, the speed of the service slows down. There's nothing you can do about this other than sit it out, unfortunately!
The level of slowdown tends to vary based on the org types. For example, Production orgs tend to be more tolerant of the Salesforce load than Developer edition orgs. However, this is not a hard and fast rule.
What does "validation queued on Salesforce" or "deployment queued on Salesforce" mean?
Gearset has uploaded your package to Salesforce, and requested that the validation or deployment be run. Salesforce has put this request in a queue for processing. Gearset is now polling Salesforce for updates and waiting for the process to begin.
Depending on the load on Salesforce, this can take a while. It's not uncommon to wait 10-15 minutes at peak times for packages to move through the queue for processing. Once the deployment begins, you'll see status updates in Gearset showing you the progress.
Checking the Salesforce service status
If you think a problem with the Salesforce service might be behind your slow validation or load, then you can check the Salesforce status for your instance or domain on this page. (If you don't know the instance information for your Salesforce org, then this article explains how to find it.)
Just enter your Instance, Domain, POD, or MID:
Here's an example result (showing no service problems):
The HISTORY tab can be helpful for identifying historical service degradation incidents. For example, here's a service incident on August 22:
Clicking on the exclamation point will display more detailed information about the incident:
Still having issues?
Contact our team and we'll be happy to help. See how.