GitHub checks
Put a readable readiness check on every push and pull request.
Put a readable readiness check on every push and pull request.
What this feature is for
GitHub checks connect repository events to PreFlight evidence. The workflow runs on GitHub Actions and reports a bounded release result without sending your repository contents to PreFlight. The important distinction is that PreFlight stores the observation alongside the app, release, provider, or customer path it belongs to. That context is what turns a signal into an operational decision.
Before you open it
GitHub access, the repository you want to protect, and a clear definition of which failures block merge or deploy.
Use a real app in the workspace and start with the smallest useful scope. A narrow, representative check gives you a stronger baseline than connecting every environment and every provider at once.
Run the workflow
Install Ship Guard for the selected repository, review the generated workflow, open a pull request, and inspect the status check and its deep links before making it required.
- Open the feature from the dashboard outcome hub.
- Choose the app and environment that match the decision you are making.
- Run or save the configuration, then wait for the evidence state to settle.
- Assign the next action to an owner before leaving the page.
Read the evidence
A check should identify the commit, policy outcome, failed condition, and the route back to the relevant dashboard evidence. A green state means the configured assertion passed at the recorded time. It does not claim that every unconfigured path is healthy. A warning is a useful lead; a failure should have a concrete owner and a verification run.
When the result is not healthy
If the status never arrives, confirm the workflow permissions and project mapping. If it arrives but is stale, inspect the webhook and commit association before rerunning.
Do not erase the failed result after fixing the underlying system. Keep the history, rerun the check, and link the new passing evidence to the deployment or incident that caused the change. This gives the team a useful before-and-after record.
Use it with the rest of PreFlight
Use GitHub with Release desk, Custom HTTP checks, and User journeys to cover code, contracts, and browser behavior. Outcome hubs are deliberately connected: Audit finds risk, Deploy decides whether to promote, Health watches the running system, Revenue verifies the money path, Growth manages discoverability, and Trust publishes safe proof. Use the related links below to move between those decisions without losing context.
