Admin override

Who can use this: Release manager and Org admin. See Roles.

Sometimes no one can satisfy a policy in time: the only member of an approver group triggered the release and self-approval is off, or the approver is away. An authorized override lets a member with policies:override release the deployment through Prodgator, on the record, instead of going around it on GitHub (which Prodgator records as a bypass).

Turn it onCopy Anchor Link

Overrides are off by default. An Org admin turns them on in the Release policy overrides card:

• Allow people to override release policies: enables the override flow. Members still need policies:override to use it.
• Allow the person who triggered the release: off by default. Like self-approval, another authorized member has to override a release you triggered. Prodgator treats you as the person who triggered it when your linked GitHub or GitLab account started the run, or when the policy already said your approval did not count because you triggered it. While this option is off, a member with no linked account for the deployment's provider cannot override, since Prodgator could not tell whether they triggered the release.

A gate can forbid overrides for its deployment environments: set Overrides to Off in the gate's approval settings (or in one deployment environment's own settings). A gate that forbids overrides wins over the organization setting. Use it for gates with strict change control, such as production.

Changing the setting writes a release_policy.override_settings_updated audit event.

Override a deploymentCopy Anchor Link

When a deployment waits on Prodgator's rule, its release policy has been evaluated and has not approved it, a member who may override sees Override next to Approve and Reject on the pending deployment in Gates. The dialog lists the enforced policies that are not satisfied and asks for:

• a reason of 10 to 500 characters, which everyone in the organization can read
• a confirmation that this releases the deployment without the policy's approval

Override and release approves Prodgator's protection rule on GitHub or GitLab, the same answer an approval sends, with your name and reason in the comment. On a deployment environment that also has GitHub required reviewers, Prodgator submits your review too when reviewer forwarding is on, as an approval does. GitHub still decides whether your review counts.

When a member cannot override, the pending deployment says why: overrides are off for the organization, a gate forbids them (named), they triggered the release and self-override is off, or their account is not linked. Org admins get a link to the override settings.

What is recordedCopy Anchor Link

• The deployment keeps the override: who, when, the reason, whether it was their own release, the gates, and the enforced policies and rules that were not satisfied at that moment. It shows an Overridden badge with the reason on Pipelines, the Gates board, the Active and History tabs and the deployment card. The History status filter has an Overridden option.
• The audit log gets a deployment.policy_overridden entry, and Organization > Audit log can filter to it.
• The organization gets a critical notification, on the same channels as a bypass.
• In dashboard widgets, the Deployments source's Governance dimension counts it as overridden, apart from governed and bypassed.

Overrides are made in the app, with Override on the pending deployment. The /v1 API has no override route; its deployment reads include the override record.

Pull request gates have their own override for one commit; see Pull request gates.

Override a promotion path resultCopy Anchor Link

An override can release a deployment whose promotion rules were not met, such as a hotfix or a release that skipped UAT. Use Override on the pending deployment with policies:override. Organization, gate and self-override settings still apply. A reason of 10 to 500 characters is required. If the enforced policy already rejected the provider request, start a new deployment request to use the pending override flow.

Compliance has separate controls: an override of a compliance decision needs compliance:override; a time-limited repository and environment break-glass needs compliance:break-glass. Both require a reason. A release-policy override does not by itself override blocking compliance, and compliance break-glass does not satisfy release-policy rules.

The promotion path records the override, actor, time and unmet rules or checks. The change timeline records Promotion path check overridden with the reason. The collector writes change.lineage_overridden to the audit log and sends a warning notification to active Org admins and members granted compliance:manage or security:triage. It is not sent to the whole organization. The lineage copy of the reason is capped at 200 characters; the deployment override retains the submitted reason.

The override records an exception; the rule or check stays unmet. Signed verification statements are not built yet. When signing is available, an overridden promotion check must be recorded as FAILED, never PASSED.