Every incident investigation I've ever done starts the same way. Something's slow or something's down, and before I look at anything else I ask: did we just ship? Then comes the ritual. One tab for the monitoring chart, one tab for the git log, eyes bouncing between them, holding timestamps in my head like I'm comparing train schedules.

The ritual is absurd when you name it plainly: the deploy times and the response times are both machine-recorded facts, and I was the join table.

So Sentinel now draws deploys directly on the chart. Connect the GitHub app, link a repository to the monitor it deploys, and every push to your default branch becomes a dashed vertical line on the response-time chart, with the commit listed underneath: who shipped, what sha, when. When response times bend right after a line, you're not correlating anymore. You're reading.

Markers sit at the start, on purpose

A marker is drawn the moment the push or deployment happens, not when the pipeline finishes. That's deliberate. The question you're answering is "what changed?", and the change starts when the deploy starts. If your pipeline takes four minutes, you'll see response times react a little to the right of the line, which is the honest shape of what happened.

If you use GitHub Deployments, the marker also learns how the story ended. A deployment that reports failure turns its marker red, so a bad ship is visible at the exact spot the chart started misbehaving.

Incidents cite their suspects

The chart is for browsing. Incidents are where the question gets urgent, so they answer it directly: any deploy from a linked repository in the hour before an incident opened is cited right next to the root cause, timed against the start. "Deploy 3f2c landed 4 minutes before this incident opened" is, in my experience, the whole diagnosis more often than not.

And monitoring can hold its breath while you ship

There's a second thing deploys and monitoring have always needed to negotiate: the deploy window itself. A restart that takes twenty seconds can page you, open an incident, and put a dent in an uptime number a client reads. The old answer was calling the pause API from your pipeline, which works and is still documented, but it's one more thing to wire.

With the app connected you can just tick "Pause during deploys" on a repo link. When a GitHub Deployment starts, the monitor pauses. When it reports a terminal state, monitoring resumes. And because a deployment that hangs forever must never become a monitor that's silently off, a failsafe resumes it after twenty minutes no matter what. Monitors you pause by hand are never touched. Your pause is yours.

The part where our own demo caught a real bug

Honesty compels me to share what happened while building this. To test the feature I created a monitor for a domain that can't exist, expecting it to sit reliably down. Instead, the live dashboard showed it flapping: down, then up with a healthy 200, every thirty seconds.

The stored data was fine. The bug was in the live updates: when a check fails before HTTP even happens, like a DNS failure, there's no status code, and the websocket event papered over that hole with a default of 200. Every open dashboard had been repainting DNS-dead sites as healthy between page loads. The deliberately broken monitor exposed it within minutes of existing, and the fix shipped the same day, drawing its own deploy marker on the way out.

That's the pitch, really. Deploys and monitoring data want to be in the same picture, because each one explains the other. Now they are.

Deploy markers work on every Sentinel plan, including free. The app reads nothing from your repositories: it consumes webhooks, holds no API credentials, and its permissions are read-only metadata. Connect it from your team's Integrations page, and your next push draws its own line.