Mark deployments in monitoring
When a deployment finishes in GitHub, record it in Runscope so alerts can be read against it.
Google for Startups AcceleratorHow Knit builds this workflow
The Agent researches both APIs and wires the trigger on one side to the action on the other — no pre-built connector required. Here is the vocabulary it has to work with.
Runscope Explore Runscope →
TriggersFires when a monitor or check in Runscope raises an alert.
Fires when an incident is opened or updated in Runscope.
Fires when a monitored site, service or alarm in Runscope changes state.
Opens a new incident or alert in Runscope.
Acknowledges an open incident in Runscope.
Resolves an incident in Runscope.
GitHub Explore GitHub →
TriggersFires when a job, build or file conversion finishes in GitHub.
Fires when a job, build or API request fails in GitHub.
Calls an GitHub endpoint with data from an earlier step.
Creates a PDF, image or converted file with GitHub.
Checks or enriches a phone number, address or IP with GitHub.
More Runscope + GitHub workflows
See all Runscope + GitHub integrations → · Browse the full workflow library →
Enterprise-grade security
Common questions
Can Knit build “Mark deployments in monitoring” between Runscope and GitHub?
Yes — describe it in the box above and Knit's Integrations Agent researches Runscope and GitHub's public API docs (or your own uploaded docs) and builds a working workflow, whether or not either app already has a pre-built connector.
How long does it take to build?
Minutes to a first working version, not weeks — you test it against real data before it goes anywhere near production.
Why connect developer tools to a monitoring tool?
Most incidents follow a change. Linking GitHub and Runscope lets engineers see what was deployed around the time an alert fired, and turn an incident into tracked work.
Can an incident create an issue for the engineering team?
Yes. When an incident opens in Runscope, you can create an issue in GitHub so the fix is tracked alongside the code.