# Automate with GitHub

> Build rules that react to GitHub activity and act back on GitHub — no scripts, no glue code.

Source: https://infranest.io/docs/automate-with-github
Last updated: 2026-10-08

---

Automate with GitHub lets you build rules that react to activity in your GitHub repositories and take action back on GitHub — no scripts required. It's for anyone managing infrastructure or incident workflows alongside a GitHub-based development team.

## Overview
- Trigger automations from GitHub events like workflow runs, issues, pull requests, pushes, releases, and deployments
- Act on GitHub automatically — create issues, merge pull requests, trigger workflows, set commit status, and more
- Combine GitHub with the rest of InfraNest, such as opening a GitHub issue when an incident starts

## Before you start

1. Go to **Integrations** and connect your GitHub account.
2. To use GitHub triggers (the **When this happens** side of a rule), you need the **InfraNest Automations** app installed — a token connection can only run GitHub actions, not trigger from GitHub events.
3. In the automation builder, GitHub triggers and actions appear together under the **GitHub** group.
4. If you choose a GitHub trigger before connecting, InfraNest will remind you to connect first.

## React to GitHub activity (triggers)

1. Start a new automation and, under **When this happens**, choose a GitHub trigger — for example **GitHub workflow run**, **GitHub issue**, **GitHub pull request**, **GitHub push**, **GitHub release**, **GitHub deployment**, **GitHub deployment status**, **GitHub commit status**, or **GitHub check run**.
2. Add **Only if** filters to narrow things down — for example only the **Branch**, only a specific **Repository**, only failures, or only your **Organization**. The **Repository** and account fields suggest your connected repos and accounts as you type.
3. Keep a few filter quirks in mind:
   - **GitHub push** events include tags and deleted branches — filter on **Branch** and **Deleted** to react only to new commits.
   - **GitHub comment (issue or PR)** fires for both issues and pull requests — filter **On a pull request** to pick one.
   - **GitHub release** fires three times per release. Add **Action equals published** so your rule runs once — the builder will offer to add this for you.
   - **Assignees (everyone on it)** matches on every issue event; **Assignee** only matches the person just assigned or unassigned.
   - **Production environment** tells a production deploy apart from a preview one.
   - **Attempt** counts workflow re-runs — 1 is the first run.
   - **Cooldown** applies per issue, workflow, commit or deployment — a cooldown on one repository never blocks another.

<!-- screenshot: github-triggers -->

<!-- docs-screenshots:start:github-triggers -->

![Automate with GitHub](/media/3f3e4253-0ff3-4612-a0a2-cad15564107e)

<!-- docs-screenshots:end:github-triggers -->

## Act on GitHub (actions)

1. Under **Do this**, select **Add action** and choose a GitHub action, such as **Trigger GitHub workflow**, **Re-run GitHub workflow**, **Re-run failed jobs**, **Cancel GitHub run**, **Create GitHub issue**, **Comment on GitHub issue**, **Update GitHub issue**, **Close GitHub issue**, **Reopen GitHub issue**, **Add issue labels**, **Remove issue label**, **Assign GitHub issue**, **Merge pull request**, **Request PR review**, **Create GitHub deployment**, **Set deployment status**, **Create GitHub release**, or **Set commit status**.
2. Choose which GitHub connection the action should run as. If you only have one, it's chosen automatically.
3. Fill in fields like **Repository (owner/repo)**, **Workflow file or id**, **Branch**, **Environment**, **Labels (comma-separated)**, **Assignees (comma-separated)** and **Reviewers** — these offer a searchable list from your connected GitHub, or you can type a value or insert a placeholder from the trigger.
4. If a list won't load, check the message under the field:
   - The connection needs to be connected again — reconnect it in **Integrations**.
   - The GitHub App is suspended — unsuspend it on GitHub under **Settings → GitHub Apps → Configure**.
   - It isn't allowed to read that list — grant the permission on GitHub.
   - It can't see that repository — add the repository to the app's access on GitHub, or use a token that can reach it.
   - GitHub couldn't be reached just now — try again shortly.

<!-- screenshot: github-actions -->

<!-- docs-screenshots:start:github-actions -->

![Automate with GitHub](/media/4308e350-63f2-4148-91b1-04fa84d973bd)

<!-- docs-screenshots:end:github-actions -->

## Start from a ready-made automation

1. Open **GitHub** under **Integrations** and look for **Ready-made automations**, or go to **Automations** and open **Template library**.
2. Select **Use** on a template, pick the repository or status page it should work with, and select **Save automation**.

<!-- screenshot: github-template -->

<!-- docs-screenshots:start:github-template -->

![Automate with GitHub](/media/221e1f49-d3e2-4c03-80ff-bc68768f9bc8)

<!-- docs-screenshots:end:github-template -->

Useful ready-made automations that connect GitHub to the rest of your setup:

- **Incident opened → open a GitHub issue**, paired with **Incident resolved → close its GitHub issue**, so issues track and close themselves automatically.
- **Certificate expiring → open a GitHub issue**, two weeks ahead.
- **Domain expiring → open a GitHub issue**, a month ahead.
- **Release published → announce on status page**, for full releases only (pre-releases are skipped).
- **GitHub workflow failed → re-run failed jobs once** — a flaky job gets one retry, then it's left for you.
- **Deployment succeeded → check it is up → set commit status** — InfraNest checks your environment right after GitHub reports the deployment and marks the commit accordingly. This check doesn't affect monitor uptime or open incidents.
- **Deployment succeeded → purge the Cloudflare cache.**
- **Deployment succeeded → announce on status page.**
- **GitHub workflow failed → open an issue & alert**, and **Certificate expiring → run a GitHub workflow**.

> [!NOTE]
The three **Deployment succeeded** automations only act on production deploys, so preview deploys don't trigger announcements or cache purges.

## Examples

1. **SSL renewal failed** → **Create GitHub issue**, add the `infrastructure` label, and set **Assignees (comma-separated)** to your DevOps team.
2. **Incident resolved** → **Comment on GitHub issue**, then **Close GitHub issue** — using **Linked records** to fill in the issue number and repository automatically. If no issue was opened for that incident, the step is skipped.
3. **GitHub pull request** merged into a branch → **Run GitHub workflow**, then **Set deployment status**.
4. A production health check passes → **Set commit status** to success.
5. **GitHub release** published → **Post status-page announcement**.

## Good to know

- A GitHub trigger only fires once GitHub is connected and the app is subscribed to that event type. If a trigger never runs, ask your administrator to check the app's event subscriptions.
- Automations you run don't trigger your own GitHub triggers again — this stops a rule from reacting to its own comments or labels endlessly.
- If two InfraNest workspaces connect the same GitHub account, automations in both will react to its events.
- When one step creates something (like an issue or deployment), later steps in the same rule can reuse it automatically.
- Requesting a review from a team needs an organization connection, not a personal one.
- Some actions show a **Pro** badge and need a higher plan.

> [!TIP]
Leave the workflow branch field empty to use the repository's default branch — it doesn't have to be called `main`.

## Troubleshooting

- **Merge pull request only merges what the rule saw.** If someone pushes new commits after the approval that started the rule, nothing is merged, and the run explains why.
- **Retries:** set **Retry on transient failure** to automatically retry a GitHub outage, timeout, or rate limit. A permanent refusal shows GitHub's own reason in **Run history**.
- If a later step points at an issue that was supposed to be created earlier (through **Linked records**) and none was created, that step is skipped rather than failed.