Deployment Status
Deployment Status is a Salesforce Setup page that monitors the progress and history of deployments to your org.
Definition
Deployment Status is a Salesforce Setup page that monitors the progress and history of deployments to your org. It lists every deployment regardless of where it came from: change sets received from connected orgs, Metadata API deployments (including pushes from Salesforce Extensions for Visual Studio Code and the Salesforce CLI), and package installations. For each one it shows the type, the user who ran it, start and completion times, and pass or fail results down to the individual component.
You reach it from Setup by entering Deployment in the Quick Find box and selecting Deployment Status. The page groups work into deployments in progress, pending (queued) deployments, and completed ones marked Succeeded or Failed. From here an admin can watch a live deployment, view detailed errors, cancel a queued or running job, and trigger a Quick Deploy of a recently validated component set. It is the single place to answer the question every admin asks during a release window: did my deployment go through, and if not, why?
Reading the Deployment Status page during a release
One page for every deployment type
A common misconception is that Deployment Status only tracks change sets. It does not. Salesforce documents the page as listing all deployments: change sets, Metadata API based deployments (which covers the VS Code extensions, the Salesforce CLI, and the Ant Migration Tool), and package installations. That breadth matters because a real org rarely uses one deployment method. An admin might receive a change set from a sandbox in the morning and a developer might push metadata through the CLI in the afternoon. Both show up on the same Deployment Status list with the same level of detail. The Type column tells you which mechanism produced each entry, so you can tell a change set apart from a CLI deploy at a glance. This is also why Deployment Status is not a legacy screen. It is the current, supported monitoring surface for production and sandbox deployments alike, and it stays useful no matter which tool your team standardizes on. When someone asks where a deploy went, this page is the answer for nearly every path metadata can travel into an org.
How the page is organized
The page sorts deployments into clear sections so you are not hunting through a flat log. Deployments in progress appear at the top with live progress indicators: one chart tracks how many components have been processed, and a second tracks Apex test execution when tests are running. Below that, pending deployments sit in a queue because Salesforce runs deployments to a given org one at a time. If you start a second deploy while one is active, it waits here rather than failing. The completed section lists finished work as either Succeeded or Failed, with the deployment name, type, the user who ran it, the start time, and, for validations, the time the validation finished. That validation timestamp is not decoration. It is what you check before relying on a Quick Deploy, because the eligibility window is measured from it. Salesforce retains this history for roughly the last 30 days, so the page is a short-term record rather than a permanent audit trail. For anything older, you export details while the entry is still listed.
Validation, deployment, and the all-or-nothing transaction
Every entry on the page is one of two operations: a validation or a deployment. A validation is a dry run. It resolves dependencies, compiles Apex, and runs the required tests, then reports success or failure without committing anything to the org. A deployment does the same work but commits the result. The important property is that a deployment is a single transaction. If any component fails, the whole deployment rolls back and the org is left exactly as it was before. There is no half-applied state from a normal failure, which is why the per-component error list matters more than the headline status. To deploy to a production org, Salesforce requires that at least 75 percent of your Apex code is covered by passing unit tests, and that gate is enforced during the deployment, not before. Sandboxes and Developer Edition orgs do not enforce the 75 percent rule, so a deploy that passes in a sandbox can still fail the coverage check in production. Watching that test chart climb on the Deployment Status page is often the first sign of whether a production deploy will clear the bar.
Quick Deploy and the validation window
Quick Deploy is the optimization that makes tight release windows workable. When you validate a change set or a Metadata API component set and it succeeds, that result becomes eligible to deploy without re-running the Apex tests. The button appears on the Deployment Status entry for the successful validation. Skipping the test run can turn a deploy that would take an hour into one that finishes in minutes, which is the difference between fitting inside a maintenance window and overrunning it. The eligibility is time limited. Salesforce documents that a recent validation qualifies for Quick Deploy when it completed successfully within the last ten days, the same components are deployed, and the tests required for the target org were run during the validation. The practical lesson is to validate close to when you plan to deploy. A validation you ran two weeks ahead of the window has already expired, so the deploy falls back to a full run with tests at exactly the moment you have the least time to spare. Treat validation as a step you do shortly before the deploy, not weeks in advance.
Debugging a failed deployment
When the status reads Failed, the headline tells you almost nothing useful. The value is in View Details, which expands the deployment into per-component results. Each component shows whether it succeeded or failed and the exact error message for the failures. The patterns repeat across orgs. A missing dependency is the most common: the change set references a field, object, or class that was never included and does not already exist in the target. A validation rule conflict appears when new metadata violates a rule that is already active in the org. Insufficient coverage shows up when a production deploy drops below 75 percent. An Apex compile error surfaces when new code calls a method or references a symbol that is not present. Because the deployment rolled back as a unit, fixing the listed components and redeploying is the normal loop, not patching a partially applied org. Reading these messages carefully, in order, is faster than guessing, since the first failure often explains the ones beneath it. The per-component view is the real debugging tool on this page.
Canceling a deployment in flight
Deployments that are queued or in progress can be canceled from the Deployment Status page. Canceling a queued deployment is clean, because nothing has started yet. Canceling one that is actively running asks Salesforce to abort safely, and it usually does, but a cancel mid-deployment is not guaranteed to be instant. The platform finishes the unit of work it is in before stopping. In practice cancel is an emergency control, not a routine action. The legitimate reasons are narrow: you targeted the wrong org, you realize the change set is wrong, or a runaway test run is going to overshoot the window. Most successful release operations never press it. A related operational note is the org lock. During a validation the source org is locked for writes against the affected metadata, and during a deployment the target org is locked. That is why Salesforce recommends running validations and deployments during off-peak hours and limiting other changes while they run. The Deployment Status page is where you confirm a job actually stopped after you cancel it.
Deployment Status next to DevOps Center and the CLI
Deployment Status is the platform-native monitor, and it sits alongside the tools teams use to build releases. Change sets are the point-and-click path, where an admin assembles components in one org and deploys the inbound set in another. The Metadata API path covers code-first workflows through the Salesforce CLI, the VS Code extensions, and the Ant Migration Tool. DevOps Center adds source control and a pipeline on top, and it has its own promotion view, yet the underlying deployments it triggers still appear on Deployment Status because they run through the same engine. So the page is not in competition with these tools. It is the common ground beneath them. Whatever your team uses to package and move metadata, the actual deploy lands here with its status, its component results, and its errors. Knowing this page well pays off across every deployment method, because it is the one screen that does not change when your tooling does. It is the dependable read on what the org actually did.
How to monitor a deployment with Deployment Status
Deployment Status is a monitoring screen, not something you create. Here is how to use it to watch a deployment through and act on the result.
- Open the page
From Setup, type Deployment in the Quick Find box and select Deployment Status. The list loads with any in-progress, pending, and completed deployments from roughly the last 30 days.
- Watch a live deployment
For a deployment that is running, read the two progress charts: one for component processing and one for Apex test execution. The test chart is your early signal for whether a production deploy will clear the 75 percent coverage gate.
- Check the result and open details
Once it lands in the completed section as Succeeded or Failed, click View Details on a failure to see per-component results and the exact error messages. Fix the named components and redeploy.
- Quick Deploy a fresh validation
If you validated first and the validation is still within its window, use Quick Deploy on that entry to commit without re-running tests. Confirm the validation completion time before relying on it.
Expands an in-progress or completed deployment to per-component status and full error text, the actionable debugging surface for failures.
Stops a queued or in-progress deployment. Clean for queued jobs; an in-progress cancel aborts as safely as the platform can but may not be instant.
Commits a recently validated component set without re-running Apex tests, available when the validation succeeded within the documented window and covers the same components.
- History is kept only for about 30 days. Export details you need to keep before the entry ages off the list.
- The 75 percent Apex coverage rule is enforced on production deploys only, so a deploy that passed in a sandbox can still fail in production.
- A Quick Deploy validation that is older than its window has expired; the deploy then runs the full test cycle when you least expect it.
- Only one deployment runs to an org at a time. A second deploy queues as Pending instead of running in parallel.
Trust & references
Cross-checked against the following references.
- Monitor Deployments (Deployment Status)Salesforce
- Deploy a Change SetSalesforce
Straight from the source - Salesforce's reference material on Deployment Status.
Hands-on resources to go deeper on Deployment Status.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does the Deployment Status page show?
Q2. When is Deployment Status useful?
Q3. How does Deployment Status complement CI/CD logs?
Discussion
Loading discussion…