GitHub

Outages as issues, in the repo that owns them.

Open an issue in a repository with a title and body you choose. For teams who already run their work out of GitHub, this puts an outage in front of the people who maintain the service without adding another tool.

Lands in the right repo. Point the connection at the repository that owns the service, so the issue reaches the people who can fix it.
Your own title and body. Write both in the notify step, with placeholders so the issue carries the specifics of the incident.
Encrypted at rest. The credentials you enter are encrypted at rest.

Start free All features

01 · When to reach for it

Where the code and the outage meet.

The advantage over a generic ticket is proximity. The issue lands in the repository whose code is responsible for the service.

One repo per service

Create a connection per repository so each monitor raises issues where that service actually lives.

Visible to maintainers

People watching the repo see the issue without needing access to your monitoring dashboard.

Fits GitHub-native teams

If your planning, code review and releases already happen in GitHub, this avoids introducing a separate tracker.

Good for open source

Public projects can surface outages in the same place contributors already look, without a paid tool in the loop.

Put it behind a Wait

An issue for a brief blip is noise. Delay it so only genuine outages create one.

Reserve it deliberately

Because flows belong to individual monitors, use issue creation only where follow-up work is actually expected.

Questions

Common questions

How do I connect GitHub to Hesklo?

Add a GitHub connection in the monitor editor sidebar with the credentials Hesklo asks for and the repository issues should be created in. Use Send test to confirm an issue appears in the right place.

Can I set the issue title and body?

Yes. The GitHub notify step lets you write both, and you can include placeholders such as flow, state, detail and duration so the issue carries the specifics of the incident.

Can different monitors post to different repositories?

Yes. Create one connection per repository and select the right one in each notify step. Since every monitor has its own flow, each service can raise issues in the repo that owns it.

Do issues close automatically when the service recovers?

Issue creation is what the GitHub step does. For an all-clear you can draw a notify step from the monitor up port. PagerDuty is the destination where the full incident lifecycle is handled automatically.