ArcRelease correlates every PagerDuty and Datadog alert to the deployments inside a 60-minute blast-radius window, then resolves the full chain down to the Jira story.
ArcRelease runs deployment incident correlation against a 60-minute blast-radius window, matching every PagerDuty or Datadog alert to the deployments that could plausibly have caused it. The chain resolves from alert to deployment to commit to pull request to Jira story in roughly 10 seconds.
Twenty minutes into the bridge call we are still arguing about whether anything even shipped this afternoon.
The alert fires on checkout, but four teams deployed in that window and none of them think it was theirs.
By the time we find the commit, the person who wrote it has gone to bed and the context is gone.
The first ten minutes of an incident are spent asking what changed. ArcRelease already knows. Every alert is matched against the deployments that could plausibly have caused it, and the chain from alert to deployment to commit to pull request to Jira story is on screen before the bridge call fills up.
ArcRelease records every deployment event from Jenkins, GitHub and GitLab with the services and commits it carried, and listens to PagerDuty incidents and Datadog monitors as they fire.
When an alert fires, ArcRelease looks back over a 60-minute window, keeps only the deployments whose blast radius includes the alerting service, and ranks the rest by proximity and overlap.
Each candidate deployment resolves to its commits, each commit to its pull request, each pull request to its Jira story, with authors and reviewers attached. About 10 seconds from alert to a named change.
Confirmed correlations become history. They raise change failure rate for that service and become a cited reason in the next Gaja preflight, so the same class of incident is harder to repeat.
ArcRelease reads from these tools and is never in the deploy path. Nothing in your pipeline changes.
It filters by blast radius first, keeping only deployments that touched the alerting service or something it depends on, then ranks the survivors by time proximity and overlap. You get ranked candidates with the reasoning shown, not a single confident guess that sends a team down the wrong path.
It is wide enough to catch the slow burners — a memory leak or a migration that degrades under load — and narrow enough to exclude unrelated deploys. It is configurable per service. Teams running latency-sensitive services often tighten it; teams with batch jobs sometimes widen it.
No, and the difference matters. Ten seconds is time to a candidate root cause: how fast you learn what changed. MTTR, or time to restore, measures how long the service is degraded and includes the fix, the deploy and verification. Correlation shortens the diagnosis, not the repair.
ArcRelease says so. If nothing shipped inside the blast-radius window, that is a real finding and it arrives in seconds: stop looking at releases and go and look at infrastructure, traffic or a dependency. Ruling out change is often the most useful thing correlation does on a bridge call.
No, either one is enough to start. PagerDuty gives you the declared incidents and Datadog gives you the monitors that fire before anyone declares one. Teams that connect both get correlation on the early signal and on the paged incident.
It changes what the first ten minutes are spent on. The bridge call opens with a named candidate deployment, its pull request and its author instead of an open question. Your escalation, comms and postmortem process stay exactly as they are.
Tell us about your release process. Connect your stack in ten minutes, run a Gaja preflight on a real release, and see the reasons behind the verdict.
Free plan · ten minute setup · we reply in one to two business days