All Documentation

Documentation Settings: The room

Schedule: started by GitHub

A server schedule starts when something happens on a repository the GitHub App covers: an issue opened, a push, a check or workflow that failed, a release, a pull request.

Beside its HTTP trigger, a schedule our servers run can start on a GitHub event. The GitHub App that reviews pull requests already receives the events; a schedule asks for the ones it wants.

Setting it up

Where to find it. Web: Settings → Schedule, press Trigger… on a server row, then the GitHub panel under the HTTP one. Made and changed on the web; the Mac and the iPhone show it on the row.

How to use it.

  1. Choose a repository the GitHub App is installed on, for your account or your team. None listed means the App is not installed yet: Settings → GitHub reviews.
  2. Tick the events: a pull request opened or pushed to, a push, an issue opened, a check that failed, a workflow that failed, a release published.
  3. Optional filters, all of which must pass: labels (any of them, on the pull request or issue), an author login, a branch (the pull request's base, or the branch pushed to), and whether drafts count.
  4. Press Start on these events. From then on each matching delivery starts the schedule once.

What the room gets

The schedule's own prompt, then the event's facts as outside material: the repository, the number and title, the author, the labels, the branch and commit, the check's conclusion, the release's tag and notes. Never the whole webhook body, and never as your words, so instructions hidden in an issue are treated as data.

Brakes

One start per schedule per delivery, so a redelivery does nothing. One run at a time per schedule, and at most one every five minutes, so a burst of pushes is one run. The run is paid for like any discussion, under the month's quota, the in-flight slots and the schedule's budget line. The webhook checks on every delivery that the schedule's owner is the installation's owner or on its team.

When to use it. Triage a new issue and draft a first reply; investigate a failed workflow and open a fix; draft release notes when a release is published; a first review pass on a pull request with a label.

When not to use it. Pull-request reviews themselves: the App reviews those on its own (see GitHub reviews), with inline comments and a merge-box check a schedule cannot post.

Further reading. Webhook events and payloads — GitHub Docs.

See Also

Not what you were looking for? The help centre answers one question at a time, and the support page says how to reach a person.