Incident Response Automation: Webhook to GitHub Workflow Control
Your incident management system sends a webhook when a P1 incident is declared. Notis immediately cancels non-critical GitHub workflows so CI resources are available for emergency patches.
Trigger
Webhook received
Notis starts this workflow when an external tool or custom backend sends an HTTP request.
Action
Cancel a workflow run
Cancels a workflow run in a github repository if it is in a cancellable state (e.g., 'in progress' or 'queued').
Why this helps
An incident happens and the team needs to deploy a fix, but CI is backed up running workflows for features that can wait. Resources are wasted on non-urgent work while critical fixes queue.
- Respond faster to incidents by freeing up CI capacity instantly
- Prioritize emergency work automatically without manual intervention
- Maintain incident focus by automating resource allocation decisions
- Reduce time-to-deployment for critical fixes
Setup
Build it in a few focused steps.
- 1Connect GitHub to Notis
- 2Identify which external system will send incident webhooks (PagerDuty, Opsgenie, custom backend, etc.)
- 3Create an automation: 'When an incident webhook is received, cancel all non-critical GitHub workflows in the emergency repository'
- 4Customize which workflows to cancel: 'cancel workflows tagged with non-critical, but preserve the emergency-deploy workflow'
- 5Generate a webhook URL from the Notis automation and configure your incident system to send to that URL
- 6Test by triggering a test incident and verifying GitHub workflows are canceled
Questions about this workflow
How does Notis know which workflows are critical vs. non-critical?
Tag your GitHub workflows with labels or names that indicate priority: run_name contains 'critical' or 'emergency', and cancel the rest. Your automation prompt specifies the pattern.
Can I automatically restart workflows after the incident is resolved?
Yes. Set up a separate webhook trigger for incident resolution: 'When incident is marked resolved, restart the standard workflow queue'.
What if a critical workflow is already running?
Notis only cancels queued or in-progress workflows that match the non-critical pattern. Your prompt can specify 'only cancel workflows that haven't started yet' for extra safety.
Does this work with GitHub Actions or other CI systems?
This focuses on GitHub Actions. For Jenkins or other systems, create a complementary automation using their APIs.
When this happens · Trigger
Do this · Action
Supported Triggers and Actions
Notis builds workflows that link Linear to GitHub. A trigger fires from one place; an action lands in another.
Linear triggers
GitHub actions
Comment Received Trigger
Triggered when a comment is received.
Accept a repository invitation
Accepts a pending repository invitation that has been issued to the authenticated user.
Issue Created Trigger
Triggered when a new issue is created.
List repositories starred by the authenticated user
Deprecated: lists repositories starred by the authenticated user, including star creation timestamps; use 'list repositories starred by the authenticated user' instead.
Issue Updated Trigger
Triggered when an issue is updated. For example labels are changed, issue status is changed, etc.
List stargazers
Deprecated: lists users who have starred a repository; use `list stargazers` instead.
Private Team Comment Created
Fires when a new comment is posted on an issue in a private Linear team (polled with the connected user's token).
Star a repository for the authenticated user
Deprecated: stars a repository for the authenticated user; use `star a repository for the authenticated user` instead.
Private Team Issue Created
Fires when a new issue appears in a private Linear team (polled with the connected user's token).
Add email for auth user
Adds one or more email addresses (which will be initially unverified) to the authenticated user's github account; use this to associate new emails, noting an email verified for another account will error, while an existing email for the current user is accepted.
Private Team Issue Properties Updated
Fires when properties on an issue change in a private Linear team (polled with the connected user's token).
Add app access restrictions
Replaces github app access restrictions for an existing protected branch; requires a json array of app slugs in the request body, where apps must be installed and have 'contents' write permissions.
Project Created
Fires when a new Linear project is created. Covers projects in both public and private teams — polls with the connected user's token, so visibility matches what the connected user can see in Linear.
Add a repository collaborator
Adds a github user as a repository collaborator, or updates their permission if already a collaborator; `permission` applies to organization-owned repositories (personal ones default to 'push' and ignore this field), and an invitation may be created or permissions updated directly.
Project Properties Updated
Fires when properties on a Linear project change (status, lead, target date, priority, etc.). Covers projects in both public and private teams — polls with the connected user's token.
Add a repository to an app installation
Adds a repository to a github app installation, granting the app access; requires authenticated user to have admin rights for the repository and access to the installation.
Connect any two apps with Notis in the middle.
Not just Linear and GitHub. Any combination from 985+ integrations.
When this happens · Trigger
Do this · Action
Save your first hour today.
7 days free trial with 20$ free usage included.
No card. Works with personal or business GitHub.