Compliance policies
Check your organization against compliance policies, run an evaluation, and override a decision with an admin reason.
Availability
The Compliance page checks your organization against a set of policies and, on the Enterprise plan, can block GitHub deployments that fail them.
Default policies
The first time anyone opens the page, Prodgator creates five policies:
| Policy | Check | Passes when |
|---|---|---|
| Require CI pass before deploy | The success rate of recent runs is at or above the threshold (100%) | |
| No critical vulnerabilities | There are no open Critical security alerts | |
| Deploy frequency SLA | At least 1 successful deployment to a protected environment in the last 7 days. Otherwise a warning, also while no gate protects an environment | |
| MTTR SLA | No recent run failed, or at least one recent run succeeded | |
| No high-severity secrets exposed | There are no open secret scanning alerts |
Each policy shows its rules, the check each rule uses, and its recent results. Admins can turn a policy on or off with its switch. Other roles see the policy's state as On or Off instead, with the note "Only admins can change this". Disabled policies are skipped.
Running an evaluation
Click Run Evaluation ( and above) to check every enabled policy against your organization's current runs, deployments and alerts. Each policy then shows passing, warning or failing, with the evidence for each rule (for example "Success rate is 92.0%, threshold is 100%").
The cards at the top show the pass rate and the number of policies passing and failing.
Security evidence
Checks like "no critical vulnerabilities" count open security findings and the scan results behind them. Their evidence names both counts, for example "2 open critical findings (5 scan results from 3 sources)", and keeps the scan results behind them (up to 500 per check; the security findings export has all).
Overriding a decision by hand
A deployment that a Block policy governs can also be answered by hand from the Gates or Pipelines page while it is still pending. That overrides Prodgator's decision, so:
- Only an can do it. Other roles see "Only an admin can override its decision here."
- The admin must give a reason of 10 to 500 characters.
- The reason is written to the audit log and starts the comment Prodgator posts on GitHub.
With no Block policy on the environment, or on a plan without blocking enforcement, Prodgator does not answer the rule and an can answer it without a reason. API keys with always have to give a reason. See Approve deployments.
From the API
API keys with can read results at . See the Public REST API.