Approve a deployment from your phone only after you can say what is shipping, who started it, and what checks passed. If any of those three is unclear, reject it or wait for a laptop. Set the environment to block self-approval so one person cannot start and approve the same run.
How approval works in a typical pipeline
Many teams gate production behind a required reviewer. In GitHub Actions, when a job targets an environment with required reviewers, the reviewer gets a notification. They open the workflow run, choose Review deployments, select the environment, optionally leave a comment, then pick Approve and deploy or Reject. After approval, the job can read the environment's secrets, provided any other protection rules also pass.
That flow works well on a phone, which is the point: a gate that waits until someone is at a desk is a gate people learn to route around. But the same convenience makes the approval easy to give without looking.
The three things to know before you tap
- What is shipping. Open the commit or pull request list for the run, not just the title. A run named "release" tells you nothing.
- Who started it. If you started it yourself, you are not a second pair of eyes.
- What passed. Check that tests and scans for this commit finished, not for an older one.
If you cannot answer all three in under a minute on the phone, that is information. Reject with a comment such as "need to review diff on laptop" and move on. A rejected run costs a rerun. A bad approval can cost an incident.
Turn on self-approval protection
GitHub's documentation notes that if the target environment is set to prevent self-approvals, you cannot approve a deployment from a workflow run you started. Turn that on for production. It matters more on mobile, because a tired engineer who triggered a hotfix is the person most likely to approve their own run to get it over with.
Refuse list for mobile approvals
Some runs should never be approved from a phone, whatever the urgency.
- Runs that change infrastructure permissions or secrets.
- Runs with a diff you could not read in full.
- Runs triggered by a pull request from a fork or an unknown contributor.
- Anything that arrived as an unexpected notification when you were not expecting a release.
That last item deserves a note. Attackers know that push notifications and chat pings train people to tap. If you get an approval request you did not expect, ask the team in a separate channel before approving. Our post on push approval fatigue covers the same habit for sign-in prompts.
Make the right thing easy
A checklist only helps if it is quick.
- Put the production reviewer list in a short, named group so the right people are notified, and not everyone.
- Require a comment on rejection, so the next person has context.
- Keep deploy runs small. A run with one change is reviewable on a phone. A run with forty changes is not.
- Keep a break glass path that does not depend on one person's phone being charged.
After the approval
Watch the first minutes. Open the deploy log or health check and confirm the release did what you expected. If something is off, you want to know while you still have the app open.
Quick check
Should I approve a deployment I did not review just because the tests passed?
No. Passing tests tell you the checks that exist were green, not that the change is what you meant to ship. Read the change list first, or reject and review later.
Does blocking self-approval slow down hotfixes?
Slightly, because a second person must act. That is the intent. Agree a backup reviewer for each environment so a hotfix does not wait on one inbox.
Sources
Last reviewed: 19 October 2026.
