GitHub Copilot App Automations: Step-by-Step Tutorial
Describe a chore once, pick a trigger, and let the Copilot app handle it on schedule. This walkthrough follows GitHub's official demo: a daily Dependabot triage that turns a morning of PR sorting into one report.
TL;DR
- An automation is a task you describe once so Copilot repeats it on a trigger — manual, hourly, daily, weekly or when an issue is created.
- Set the schedule to just before your workday (the demo uses 9:00 AM) and decide between a cloud run and your own machine.
- Write the prompt in plain English, pick the project, then use Create and run to test the first pass without waiting for the schedule.
- The run ends as one report: PRs grouped by risk, safe merges flagged, and a best-next-steps summary you can turn into a new session with one click.
Automate recurring developer tasks with the GitHub Copilot app
Channel: GitHub4:13
About automations
Docs: docs.github.com
Automations in the GitHub Copilot app
Docs: docs.github.com
Screenshots come from the official GitHub tutorial video; the trigger list and cloud-run details were cross-checked against the docs pages linked above.
Every frame links back to the exact moment in the source recording. GitHub and Copilot are trademarks of GitHub, Inc. This is an independent guide.
Create your first automation, step by step
Set up the automation
- 1
Create a new automation and name it
In the Copilot app, open the Automations section and click New automation. Give it a name you will recognize in a list later — the demo uses “Daily Dependabot triage”. The name is for you; the prompt is what Copilot follows.
Name the automation after the job it does, not the tool.Watch at 1:28 - 2
Pick the trigger that matches the routine
Five triggers are on the menu: Manual for when you want to fire it yourself, Hourly, Daily and Weekly for schedules, and Issue created, which runs whenever a new issue appears. The demo leaves Daily at 9:00 AM — just before the workday starts.
Manual while you experiment, scheduled once it earns trust.Watch at 1:00 - 3
Describe the job once, in plain English
The prompt works like a normal Copilot session. The demo asks Copilot to review open Dependabot PRs, group them by risk, call out safe merges, separate minor bumps from major version updates, confirm CI passes, and finish with a short summary of the best next steps.
If you would type it into a session, it works as an automation.Watch at 2:00 - 4
Point it at the right project
Below the prompt, choose the repository the automation should work in — the demo picks tailspin-toys, where all the Dependabot PRs live. This is also where you adjust the model and agent controls, exactly like in an interactive session.
One automation, one project keeps the report focused.Watch at 2:08
Launch and watch the first run
- 5
Save it and launch the first run right away
Click Create to save it for the 9:00 AM schedule — or open the arrow next to Create and pick Create and run, which saves the automation and starts a manual run immediately so you can watch it work without waiting.
Create and run is the fastest way to test your prompt.Watch at 2:20 - 6
Watch it appear under Your automations
The saved automation shows up as a card on the Automations screen with its trigger badge and a live status. From here you can run it manually any time with the play control, or edit the prompt as you learn what you actually want.
The card shows the trigger, the repo and the last run at a glance.Watch at 2:26 - 7
Read the report instead of the PR list
A task that used to eat the morning comes back as one organized report. The demo's run groups Dependabot PRs by risk level, marks the safe ones as Passing, and keeps the header honest with a “Last run 1m ago” stamp.
Risk groups and CI status replace an inbox of update PRs.Watch at 3:00
Act on the results
- 8
Separate safe merges from major upgrades
Low and medium rows — bundled dev-dependency bumps and minor updates — are cleared to merge after a quick sanity pass. High rows say Do not merge: major framework or integration upgrades that deserve their own review.
The report's job is to make the safe/no-go split obvious.Watch at 3:08 - 9
Follow the best-next-steps summary
Beyond the table, Copilot suggests an order of operations: merge the safe ones first, treat the isolated major bump as optional, and handle the related Astro upgrades as one coordinated migration because they are already breaking CI.
The summary tells you what to do, in what order, and why.Watch at 3:20 - 10
Turn a finding into a follow-up session
When the report surfaces real work — like an Astro 6 upgrade — you don't need to re-explain anything. Type it into the composer under the report and Copilot starts a new session with the context it already has, while the automation entry keeps the audit trail.
The report becomes the starting point for the fix.Watch at 3:28
Cloud or local: choosing where automations run
The Run in the cloud toggle decides where the agent executes, and it changes more than just where the process lives. The official demo keeps it off and runs locally; here is how the two modes differ in practice.
- 1Local runs execute on your machine, so they only happen while your computer is on. They are the natural first step while a prompt is still experimental, and per the docs, local automations are also the only kind that accept a custom CRON expression.
- 2Cloud runs keep working “even when your computer is off” — that is the toggle's own description. They need the Copilot cloud agent enabled for the repository, and they act inside the repo rather than your workspace.
- 3With cloud mode, a Tools dropdown limits what Copilot may do — pushing changes, updating labels, opening pull requests. The docs advise selecting only the tools the task requires, which keeps an unattended job on a short leash.
- 4Cost and access differ too: cloud automations require a private or internal repository and bill each run's Actions minutes and AI credits to the person who created the automation. Anyone with write access can create one.
A practical default: iterate locally with Create and run until the report looks right, then flip the toggle and let the schedule take over. And if one trigger is not enough, the app lets you add another — an automation fires when any of its triggers occur.
What to automate first (and how to debug a run)
GitHub's own advice: start with a boring task you already do on autopilot. If you need inspiration, the Automations screen ships with templates — Issue triage, Changelog draft and Repo audit — that make good starting points.
- 1Daily housekeeping is the sweet spot: sorting Dependabot PRs, triaging new issues into buckets, or checking that CI is green across a repo. The rule of thumb from the video: if it has a clear rubric, it can run unattended.
- 2Start from a template, then rewrite the prompt in the same style you would use for a session — concrete verbs, explicit grouping, a defined output. The demo prompt asks for groups, labels and a summary, not just “look at the PRs”.
- 3Automations are not a black box: every run lands in the Automations section with what ran, when, and what it did. If a result looks off, open the run and read the session before touching the prompt.
- 4When the report points at real work, chain a follow-up session straight from the result — the Astro 6 upgrade in the demo started this way, inheriting the automation's context.
- 5Prompt not producing what you want? Edit the automation, tighten the ask, and use Create and run to test immediately instead of waiting for the next scheduled fire.
Treat automations like cron jobs with a brain: small, well-described tasks that run often beat giant vague ones that run monthly. Once a routine earns trust on a schedule, clone it for the next repository.