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 GitLab Issues.
One access token and a project, and a confirmed outage becomes an issue in the board your team already plans in.
What lands in GitLab
Everything the alert pipeline creates in GitLab 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 board filter or a rule can pick them out of the backlog.
Write a readable description
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 project that owns the site.
Work with a self-hosted instance
Your own GitLab is reached through its own base URL, which has to be https and is checked against internal targets before it is called.
A project per client
Each channel names its own project, so a client's outage lands on the board the people who look after that client actually plan in.
File a test issue
The dashboard creates one issue marked TEST while you set the channel up, so a wrong project id is caught before the first outage.
Ask for one scoped token
A project or personal access token with the api scope 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 an access token
Create a project or personal access token with the api scope for the project the issues should land in. Newer GitLab hides it behind Legacy token in the generate dropdown.
Access token
glpat-xxxxxxxxxxxxxxxxxxxxStored encrypted
2. Name the project
Enter the numeric project id or the group and project path, and paste the token.
3. Save and test
Add the instance base URL if you are self-hosted, assign the monitors the channel covers, and file the test issue.
Before you connect GitLab.
No. The recovery is filed as its own issue rather than closing the first one, so the outage keeps its history and its discussion. Both carry the uptimeify label, which is enough for a rule to close them for you.
Either. The numeric id from the project's overview works, and so does the group and project path, which is the readable option.
Yes. Enter the base URL of your instance. Only https is accepted, and the address is resolved and checked against internal and loopback targets before a request is sent.
No. Your quota covers monitors and the monthly SMS and voice allowance. Issues created in GitLab, GitHub 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 GitLab once, and every confirmed outage arrives as an issue in the project that owns the site.