Create an issue on a confirmed outage
The issue is created once enough independent EU locations fail the check often enough in a row, both thresholds sit in your package, not on the first failed request.
Use Uptimeify with Linear.
One API key and a team, and a confirmed outage arrives in the cycle your team is already working through.
What lands in Linear
Everything the alert pipeline creates in Linear 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.
Speak the GraphQL API
Issues are created through the documented issueCreate mutation, and a mutation that does not report success is recorded as a failure.
Land in the team you choose
The team id on the channel decides where the issue appears, so alerts follow the team that owns the site.
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 becomes an issue of its own, in the same team.
A team per client
Each channel carries its own team id and key, so a client's outage reaches the people who look after that client instead of everyone.
File a test issue
The dashboard creates one issue marked TEST while you set the channel up, so a wrong team id is caught before the first outage.
Keep the API key encrypted
The personal API key is stored encrypted rather than as plain text in the channel configuration.
Teams that run their monitoring on Uptimeify
Minutes to set up. Then it runs on its own.
1. Create a personal API key
In Linear open Settings, then Account, then Security and access, then personal API keys, and create one.
2. Take the team id
Copy the team UUID from the team settings or read it out of a team URL.
API key
lin_api_xxxxxxxxxxxxxxxxStored encrypted
3. Paste both into Uptimeify
Add key and team id as a Linear channel, assign the monitors it covers, and file the test issue.
Before you connect Linear.
In the team whose id you put on the channel, in that team's default workflow state. From there it moves like any other issue your team triages.
No. The recovery is filed as its own issue rather than closing the first one, so the outage keeps its history and whatever state your team moved it to.
A GraphQL response that does not report success is recorded as a failed delivery, not as a sent alert, so a revoked key or a wrong team id shows up under History & Logs → Alerts instead of going quiet.
No. Your quota covers monitors and the monthly SMS and voice allowance. Issues created in Linear, Jira or GitHub 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 Linear once, and every confirmed outage arrives as an issue in the team that owns the site.