[GH-ISSUE #671] Github Issues

kerem commented

2026-02-25 23:42:37 +03:00

Owner

Originally created by @andres-usheru on GitHub (Jun 23, 2022).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/671

To create an issue in Github issues when an alert fires

Originally created by @andres-usheru on GitHub (Jun 23, 2022). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/671 To create an issue in Github issues when an alert fires

kerem

2026-02-25 23:42:37 +03:00

closed this issue
added the
new integration
label

kerem commented

2026-02-25 23:42:38 +03:00

Author

Owner

@fukawi2 commented on GitHub (Jun 7, 2023):

This would be really useful for us too, so adding my +1

@fukawi2 commented on GitHub (Jun 7, 2023): This would be really useful for us too, so adding my +1

kerem commented

2026-02-25 23:42:38 +03:00

Author

Owner

@JPaulMora commented on GitHub (Apr 17, 2024):

I can help develop this, anything I should consider @cuu508?

@JPaulMora commented on GitHub (Apr 17, 2024): I can help develop this, anything I should consider @cuu508?

kerem commented

2026-02-25 23:42:38 +03:00

Author

Owner

@JPaulMora commented on GitHub (Apr 17, 2024):

Okay I have started work on this, seems that the Github API does support what we're looking for, however I have some questions about implementation.

Currently a single integration can be used for many checks, for that we'd have to consider

Either the PAT should have very broad permissions to address multimple issues across multiple user's repos
Setup each check with an optional github URL and PAT (this is the right technical solution, but how many checks would actually use this?)

@JPaulMora commented on GitHub (Apr 17, 2024): Okay I have started work on this, seems that the Github API does support what we're looking for, however I have some questions about implementation. Currently a single integration can be used for many checks, for that we'd have to consider 1. Either the PAT should have very broad permissions to address multimple issues across multiple user's repos 2. Setup each check with an optional github URL and PAT (this is the right technical solution, but how many checks would actually use this?)

kerem commented

2026-02-25 23:42:38 +03:00

Author

Owner

@cuu508 commented on GitHub (Apr 18, 2024):

The way I'm imagining the integration would work is – when a check goes down, Healthchecks creates a new GitHub issue titled something like "<check-name> is DOWN" and more details in the issue body. For that I think we would need an access token with a read/write access to issues. Looks like that's possible: https://stackoverflow.com/a/78226880/5821

The integration could also comment on the issue when the check goes back up, but that's in the "nice to have" category.

@cuu508 commented on GitHub (Apr 18, 2024): The way I'm imagining the integration would work is – when a check goes down, Healthchecks creates a new GitHub issue titled something like "<check-name> is DOWN" and more details in the issue body. For that I think we would need an access token with a read/write access to issues. Looks like that's possible: https://stackoverflow.com/a/78226880/5821 The integration could also comment on the issue when the check goes back up, but that's in the "nice to have" category.

kerem commented

2026-02-25 23:42:38 +03:00

Author

Owner

@fukawi2 commented on GitHub (Apr 18, 2024):

That's basically what I was imagining. The "integration" would be configured to create the issue in a specific repository. Ideally with (optional) Labels added to the issue.

Commenting / closing it when the check goes back up would only be a "nice to have" feature IMO too.

@fukawi2 commented on GitHub (Apr 18, 2024): That's basically what I was imagining. The "integration" would be configured to create the issue in a specific repository. Ideally with (optional) Labels added to the issue. Commenting / closing it when the check goes back up would only be a "nice to have" feature IMO too.

kerem commented

2026-02-25 23:42:38 +03:00

Author

Owner

@cuu508 commented on GitHub (Apr 18, 2024):

I can help develop this, anything I should consider @cuu508?

Alright, happy to review a PR.

There's a checklist for developing a new integration in CONTRIBUTING.md

@cuu508 commented on GitHub (Apr 18, 2024): > I can help develop this, anything I should consider @cuu508? Alright, happy to review a PR. There's a checklist for developing a new integration in [CONTRIBUTING.md](https://github.com/healthchecks/healthchecks/blob/master/CONTRIBUTING.md)

kerem commented

2026-02-25 23:42:38 +03:00

Author

Owner

@cuu508 commented on GitHub (Apr 18, 2024):

Regarding labels, GitHub API docs have this note:

Only users with push access can set labels for new issues. Labels are silently dropped otherwise.

I'm not sure but I assume API actions performed with a personal access token would show up as performed by the user who created the PAT. And there's a good chance this user does have push access.

What labels would we want to set? Isn't every repository different in how it's using the labels?

Regarding commenting on issues, or closing issues when a check goes up, I think this will be tricky. When we create a new issue, GitHub will report back the issue number. We don't have a way to store the issue number, so we can find the right issue to comment on, or close later.

A sort-of similar integration is Trello. This integration only creates Trello cards, it does not comment on them or archive them.

@cuu508 commented on GitHub (Apr 18, 2024): Regarding labels, GitHub API docs have this note: > Only users with push access can set labels for new issues. Labels are silently dropped otherwise. I'm not sure but I assume API actions performed with a personal access token would show up as performed by the user who created the PAT. And there's a good chance this user does have push access. What labels would we want to set? Isn't every repository different in how it's using the labels? --- Regarding commenting on issues, or closing issues when a check goes up, I think this will be tricky. When we create a new issue, GitHub will report back the issue number. We don't have a way to store the issue number, so we can find the right issue to comment on, or close later. A sort-of similar integration is Trello. This integration only creates Trello cards, it does not comment on them or archive them.

kerem commented

2026-02-25 23:42:38 +03:00

Author

Owner

@JPaulMora commented on GitHub (Apr 18, 2024):

What I was thinking is, if we're gonna configure the repo and PAT at the notification level there would only be a single global repository we could notify issues to. eg I would not be able to monitor/alert multiple repos, right?

@JPaulMora commented on GitHub (Apr 18, 2024): What I was thinking is, if we're gonna configure the repo and PAT at the notification level there would only be a single global repository we could notify issues to. eg I would not be able to monitor/alert multiple repos, right?

kerem commented

2026-02-25 23:42:38 +03:00

Author

Owner

@cuu508 commented on GitHub (Apr 18, 2024):

@JPaulMora yes, but that's how the other integrations work as well: when you set up a Slack integration, you select a channel, and the integration later only posts to that channel. When you set up a Trello integration, you select a board and a list, and it only adds cards to that single list. When you set up a Telegram integration, you select a chat group, and the integration only posts to that one group.

Users can set up multiple integrations of the same type though, each with different settings. You could have two GitHub integrations in the same project, one creating issues in repo ABC, and the other creating issues in repo XYZ. Then you would assign one or the other integration to checks as needed.

@cuu508 commented on GitHub (Apr 18, 2024): @JPaulMora yes, but that's how the other integrations work as well: when you set up a Slack integration, you select a channel, and the integration later only posts to that channel. When you set up a Trello integration, you select a board and a list, and it only adds cards to that single list. When you set up a Telegram integration, you select a chat group, and the integration only posts to that one group. Users can set up multiple integrations of the same type though, each with different settings. You could have two GitHub integrations in the same project, one creating issues in repo ABC, and the other creating issues in repo XYZ. Then you would assign one or the other integration to checks as needed.

kerem commented

2026-02-25 23:42:38 +03:00

Author

Owner

@fukawi2 commented on GitHub (Apr 19, 2024):

Only users with push access can set labels for new issues. Labels are silently dropped otherwise.

Well at least if the PAT doesn't have the permissions, they would be silently dropped (rather than causing an error).

What labels would we want to set? Isn't every repository different in how it's using the labels?

That would be configurable in the integration. In our specific case, we have various labels that are tied to webhooks that "do things". As an example, we have a label ("Infra") that when added to an issue, auto-assigns a random member of our Infra team.

So the workflow I'm envisaging with this integration is:

Check goes down
Create a GH Issue (with the appropriate labels, configured per integration)
Our auto-assigner randomly picks a team member to assign the GH Issue to who will then investigate the check.

We have 1 and 3, just need 2 to join them together 😄

Regarding commenting on issues, or closing issues when a check goes up, I think this will be tricky.

Yeah, it's definitely an optional extra, not a hard requirement IMO.

@fukawi2 commented on GitHub (Apr 19, 2024): > Only users with push access can set labels for new issues. Labels are silently dropped otherwise. Well at least if the PAT doesn't have the permissions, they would be silently dropped (rather than causing an error). > What labels would we want to set? Isn't every repository different in how it's using the labels? That would be configurable in the integration. In our specific case, we have various labels that are tied to webhooks that "do things". As an example, we have a label ("Infra") that when added to an issue, auto-assigns a random member of our Infra team. So the workflow I'm envisaging with this integration is: 1. Check goes down 2. Create a GH Issue (with the appropriate labels, configured per integration) 3. Our auto-assigner randomly picks a team member to assign the GH Issue to who will then investigate the check. We have 1 and 3, just need 2 to join them together 😄 --- > Regarding commenting on issues, or closing issues when a check goes up, I think this will be tricky. Yeah, it's definitely an optional extra, not a hard requirement IMO.

kerem commented

2026-02-25 23:42:38 +03:00

Author

Owner

@cuu508 commented on GitHub (Feb 18, 2025):

I had a closer look at authentication options.

We previously discussed using personal access tokens. These would be the easiest from the implementation perspective – Healthchecks would provide instructions to the user how to generate a PAT, take the PAT from the user, then use it in the "Create Issue" API call. Drawbacks:

GitHub docs recommend PATs for short-lived scripts, for bespoke developer-y things. GitHub docs recommend against using them in production apps.
PATs expire and need to be regenerated regularly
PATs work on behalf of the user, the created issues will appear as created by the user (not created by Healthchecks)
User experience is not ideal – regular users should not need to follow multi-step instructions to go into Settings / Developer Settings, pick permissions, copy/paste cryptic strings around

Looking at other options, GitHub has two types of apps that can be used to acquire access tokens, OAuth apps and GitHub apps.

The OAuth app option seems relatively straightforward: I register an OAuth app which gives client id and client secret. End user authenticates via OAuth, which in the end gives us an access token ("gho_***") which we can use with the "Create Issue" API call. Drawbacks:

Same as PATs, OAuth access tokens work on behalf of the user, the created issues will appear as created by the user (not created by Healthchecks)
OAuth apps do not support fine-grained permissions. There's no option to only grant read/write access to issues in a specific repository. The closest OAuth scope is "repo" which gives access to all repos the user has access to, and gives access not only to issues but also code, PRs, etc.
If an user is removed from organization, their OAuth credentials stop working too
Throughout GitHub docs there are recommendations to prefer GitHub apps over OAuth apps. OAuth apps seem like the legacy option.

Finally, there's GitHub apps. There's fine-grained permissions, and there's option to perform API actions as the app, not on behalf of the user. Yay! The only problem is I'm unsure how to properly and securely use them for the Healthchecks use case. The best I've come up so far is:

I register a GitHub app. This gives me client id, client secret, and private key for generating JWTs
During onboarding, Healthchecks directs the user to app's installation page: https://github.com/apps/{app-id}/installations/new
On that page, the user selects whether to install the app in their account or in an organization account
Next up, on the same page, the user selects whether to grant access to all repos or to specific repos
GitHub redirects back to Healthchecks, we receive "code" (for exchanging to user access token) and installation_id
Healthchecks calls https://github.com/login/oauth/access_token to exchange code for an user access token ("ghu_***")
Using the user access token from the previous step, Healthchecks calls https://api.github.com/user/installations to retrieve the installations the user has access to
Healthchecks presents the list of installations to the user, user selects one
Healthchecks calls https://api.github.com/app/installations/{installation-id}/access_tokens to acquire installation access token ("ghs_***") for the selected installation
Using the installation access token from the previous step, Healthchecks calls https://api.github.com/installation/repositories to retrieve the list of repos
Healthchecks presents the list of repos to the user, user selects one
Healthchecks stores the installation id and the selected repo in the database

When it is time to send an alert:

Healthchecks looks up installation id and repo name from the database
Healthchecks calls https://api.github.com/app/installations/{installation-id}/access_tokens to acquire installation access token
Healthchecks calls the "Create Issue" API call using the installation access token

I'm not at all sure I got the flow right. Initially I thought the user access token is not needed at all, as soon as we get the installation_id back from the GitHub we can go create installation access token, and create issues using it! That's what ChatGPT cheerfully recommended too! Problem is, if Eve somehow finds out Alice's installation_id, it would be straightforward for Eve to set up GitHub integration pointing to one of Alice's repos. Basically the same issue as described here. In my mind, by acquiring the user access token and checking what installations the user has access to it, we prevent against it. But I'm not sure.

If anyone has experience with GitHub apps and GitHub authentication and can share advice, I would very much appreciate it!

@cuu508 commented on GitHub (Feb 18, 2025): I had a closer look at authentication options. We previously discussed using **personal access tokens**. These would be the easiest from the implementation perspective – Healthchecks would provide instructions to the user how to generate a PAT, take the PAT from the user, then use it in the "Create Issue" API call. Drawbacks: * GitHub docs recommend PATs for short-lived scripts, for bespoke developer-y things. GitHub docs recommend against using them in production apps. * PATs expire and need to be regenerated regularly * PATs work on behalf of the user, the created issues will appear as created by the user (not created by Healthchecks) * User experience is not ideal – regular users should not need to follow multi-step instructions to go into *Settings / Developer Settings*, pick permissions, copy/paste cryptic strings around Looking at other options, GitHub has two types of apps that can be used to acquire access tokens, OAuth apps and GitHub apps. The **OAuth app** option seems relatively straightforward: I register an OAuth app which gives client id and client secret. End user authenticates via OAuth, which in the end gives us an access token ("gho_***") which we can use with the "Create Issue" API call. Drawbacks: * Same as PATs, OAuth access tokens work on behalf of the user, the created issues will appear as created by the user (not created by Healthchecks) * OAuth apps do not support fine-grained permissions. There's no option to only grant read/write access to issues in a specific repository. The closest OAuth scope is "repo" which gives access to all repos the user has access to, and gives access not only to issues but also code, PRs, etc. * If an user is removed from organization, their OAuth credentials stop working too * Throughout GitHub docs there are recommendations to prefer GitHub apps over OAuth apps. OAuth apps seem like the legacy option. Finally, there's **GitHub apps**. There's fine-grained permissions, and there's option to perform API actions as the app, not on behalf of the user. Yay! The only problem is I'm unsure how to properly and securely use them for the Healthchecks use case. The best I've come up so far is: * I register a GitHub app. This gives me client id, client secret, and private key for generating JWTs * During onboarding, Healthchecks directs the user to app's installation page: `https://github.com/apps/{app-id}/installations/new` * On that page, the user selects whether to install the app in their account or in an organization account * Next up, on the same page, the user selects whether to grant access to all repos or to specific repos * GitHub redirects back to Healthchecks, we receive "code" (for exchanging to user access token) and installation_id * Healthchecks calls `https://github.com/login/oauth/access_token` to exchange code for an user access token ("ghu_***") * Using the user access token from the previous step, Healthchecks calls `https://api.github.com/user/installations` to retrieve the installations the user has access to * Healthchecks presents the list of installations to the user, user selects one * Healthchecks calls `https://api.github.com/app/installations/{installation-id}/access_tokens` to acquire installation access token ("ghs_***") for the selected installation * Using the installation access token from the previous step, Healthchecks calls `https://api.github.com/installation/repositories` to retrieve the list of repos * Healthchecks presents the list of repos to the user, user selects one * Healthchecks stores the installation id and the selected repo in the database When it is time to send an alert: * Healthchecks looks up installation id and repo name from the database * Healthchecks calls `https://api.github.com/app/installations/{installation-id}/access_tokens` to acquire installation access token * Healthchecks calls the "Create Issue" API call using the installation access token I'm not at all sure I got the flow right. Initially I thought the user access token is not needed at all, as soon as we get the installation_id back from the GitHub we can go create installation access token, and create issues using it! That's what ChatGPT cheerfully recommended too! Problem is, if Eve somehow finds out Alice's installation_id, it would be straightforward for Eve to set up GitHub integration pointing to one of Alice's repos. Basically the same issue [as described here](https://stackoverflow.com/questions/65145343/how-to-securely-associate-a-github-app-install-id-with-the-account-of-a-website). In my mind, by acquiring the user access token and checking what installations the user has access to it, we prevent against it. But I'm not sure. If anyone has experience with GitHub apps and GitHub authentication and can share advice, I would very much appreciate it!

kerem commented

2026-02-25 23:42:38 +03:00

Author

Owner

@cuu508 commented on GitHub (Feb 19, 2025):

Revised flow:

In Healthchecks, the user clicks on a "Connect GitHub" button
Healthchecks performs an OAuth web application flow to get user's access token:
- Healthchecks redirects the user to https://github.com/login/oauth/authorize?client_id=...&state=....
- User accepts authorization request, GitHub redirects back to my app, and passes a code query parameter
- Healthchecks exchanges the code for user access token ("ghu_***") by calling https://github.com/login/oauth/access_token
Healthchecks looks up what installations the user has access to by calling https://api.github.com/user/installations and using user's access token for authentication
For each installation, Healthchecks loads the list of repos by calling https://api.github.com/user/installations/INSTALLATION_ID/repositories and using user's access token for authentication
Healthchecks presents the list of available repos to the user and asks the user to pick one
The user picks a repo. Healthchecks stores the selected repo name and corresponding installation_id in the database

When Healthchecks presents the list of available repos, it should also include a comment along the lines of "Don't see the repo you are looking for? [Click Here] to install Healthchecks in you GithHub personal or organization account". The link would take the user to the GitHub app's installation page.

@cuu508 commented on GitHub (Feb 19, 2025): Revised flow: * In Healthchecks, the user clicks on a "Connect GitHub" button * Healthchecks performs an [OAuth web application flow](https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-a-user-access-token-for-a-github-app#using-the-web-application-flow-to-generate-a-user-access-token) to get user's access token: * Healthchecks redirects the user to `https://github.com/login/oauth/authorize?client_id=...&state=....` * User accepts authorization request, GitHub redirects back to my app, and passes a code query parameter * Healthchecks exchanges the code for user access token ("ghu_***") by calling `https://github.com/login/oauth/access_token` * Healthchecks looks up what installations the user has access to by calling `https://api.github.com/user/installations` and **using user's access token for authentication** * For each installation, Healthchecks loads the list of repos by calling `https://api.github.com/user/installations/INSTALLATION_ID/repositories` and **using user's access token for authentication** * Healthchecks presents the list of available repos to the user and asks the user to pick one * The user picks a repo. Healthchecks stores the selected repo name and corresponding installation_id in the database When Healthchecks presents the list of available repos, it should also include a comment along the lines of "Don't see the repo you are looking for? [Click Here] to install Healthchecks in you GithHub personal or organization account". The link would take the user to the GitHub app's installation page.

kerem commented

2026-02-25 23:42:38 +03:00

Author

Owner

@cuu508 commented on GitHub (Feb 26, 2025):

I have deployed the first, experimental version of GitHub integration to Healthchecks.io. Anyone interested is welcome to try it out, and I will appreciate all feedback.

@cuu508 commented on GitHub (Feb 26, 2025): I have deployed the first, experimental version of GitHub integration to Healthchecks.io. Anyone interested is welcome to try it out, and I will appreciate all feedback.

kerem commented

2026-02-25 23:42:38 +03:00

Author

Owner

@fukawi2 commented on GitHub (Feb 27, 2025):

Amazing! I just tested it, it's perfect for us, thank-you! 👍 ❤

@fukawi2 commented on GitHub (Feb 27, 2025): Amazing! I just tested it, it's perfect for us, thank-you! 👍 ❤

kerem commented

2026-02-25 23:42:38 +03:00

Author

Owner

@cuu508 commented on GitHub (Mar 5, 2025):

Blog post: https://blog.healthchecks.io/2025/03/new-integration-github-issues/

@cuu508 commented on GitHub (Mar 5, 2025): Blog post: https://blog.healthchecks.io/2025/03/new-integration-github-issues/

kerem referenced this issue

2026-02-25 23:42:54 +03:00

[GH-ISSUE #815] My checks started to fail after the grace period, even when they ran. #572

kerem referenced this issue

2026-02-26 00:30:17 +03:00

[PR #483] [CLOSED] Changing static height and width to be constraints #970

Rows
Columns

[GH-ISSUE #671] Github Issues #483