Open an issue on a confirmed outage
The issue is created once enough independent EU locations fail the check often enough in a row, not on the first failed request; both thresholds sit in your package.
Use Uptimeify with GitHub Issues.
One fine grained token and a repository name, and a confirmed outage becomes an issue where the code that serves the site already lives.
What lands in GitHub
Everything the alert pipeline creates in GitHub is on this list, and nothing beyond it. Read it once and you know what your team will see.
File the recovery as its own issue
The all clear arrives as a second issue carrying the time it resolved and how many minutes the site was gone.
Label every issue
Each issue is created with the labels uptimeify and monitoring, so a filter or an automation can pick them out of the backlog.
Write a readable body
URL, customer, organisation, the error with its status code, the checking locations and the times arrive as a Markdown list.
Report a failing certificate
A TLS certificate that has crossed into its critical window opens an issue of its own, in the repository that owns the site.
Work against GitHub Enterprise
A self hosted instance is reached through its own API base URL, which has to be https, and is otherwise treated like github.com.
A repository per client
Each channel names its own repository, so a client's outage lands in the repo the people who look after that client actually watch.
File a test issue
The dashboard creates one issue marked TEST while you set the channel up, so a wrong repository name is caught before the first outage.
Ask for the narrowest token
A fine grained token with read and write on issues is enough, and it is stored encrypted rather than as plain text.
Teams that run their monitoring on Uptimeify
Minutes to set up. Then it runs on its own.
1. Create a fine grained token
Under Settings and Developer settings, create a fine grained personal access token with read and write on issues for the repository.
Personal access token
github_pat_11ABC...Stored encrypted
2. Name the repository
Enter the repository as owner and repo, paste the token, and add the API base URL if you are on GitHub Enterprise.
3. Save and test
Assign the monitors the channel covers and file the test issue, so the first real outage is not the first attempt.
Before you connect GitHub.
No. The recovery is filed as its own issue rather than closing the first one, so the outage keeps its history and its comments. Both carry the uptimeify label, which is enough for an action to close them for you.
Read and write on issues, on the one repository you name. A fine grained token scoped that way cannot touch your code, and it is stored encrypted.
Yes. Enter the API base URL of your instance next to the repository. Only https is accepted, and the request otherwise looks exactly like the one github.com receives.
No. Your quota covers monitors and the monthly SMS and voice allowance. Issues created in GitHub, GitLab or Jira do not draw on it.
No. An issue is created for the confirmed outage, not per failed request, and how many re-checks confirmation takes is yours to set per package.
Every alert, where your team already works.
Connect GitHub once, and every confirmed outage arrives as an issue in the repository that owns the site.