Devin Oncall: Letting an Agent Take the First Look at Alerts

Honestly, I do not know yet whether Devin Oncall is good or bad for me. After a full day of talking to agents and managing project work, being triggered again by an error just when I want to rest properly can be disruptive. Of course, you can arrange it around your own routine, and it is good to stay on top of projects.

This is a personal impression from using it on ongoing projects, not a measured test, and I did not record the dates, alert sources or alert volume.

What changed

Cognition introduced Devin Oncall on X on October 15, 2026, describing it as Devin automatically investigating alerts and bugs to help teams diagnose and resolve production incidents. Devin's documentation describes three parts: Responders, which investigate and fix alerts, bug reports and support questions as they arrive; Incidents, which find the root cause and drive an incident to resolution; and Reports, which summarize what is driving alerts, bugs and incidents.

Setup is done once per organization. An admin opens Oncall, connects at least one telemetry tool, and Devin then spends what the documentation says is usually one to two hours learning the systems and writing skills that every Oncall session uses.

How the handoff works

A responder watches one integration and can have up to ten triggers: a Slack channel message or user-group mention, a Microsoft Teams channel message, or PagerDuty incident events. Devin groups repeated events into a single issue, so a noisy alert is investigated once. Responders come in two types, Alerts and Support plus Bugs, and the type cannot be changed after creation.

Incidents is built for teams that open a new Slack channel for each incident. Devin joins channels that match a name prefix and posts a likely root cause. In proactive mode it keeps posting updates and maintains an incident report; a one-shot mode posts a root cause with a confidence level and then stops.

This sits next to the earlier Devin Field Note on cloud tasks and review. There, the handoff started with a written task. Here, it starts with an alert, before anyone has described the problem.

I am not assessing the accuracy of its root-cause findings or the quality of its fix PRs here; my impression is about how it fits into a working day.

Limits worth knowing

Responders have ACU and invocation limits, as automations do, so Oncall work consumes usage. Incidents require Slack to be connected, only public channels can be auto-joined, and in an enterprise only one organization at a time can have incidents enabled. Cognition's statement that Oncall already handles thousands of alerts a day for large companies is a vendor claim that this draft did not verify.

Where I would draw the line

I would suggest it for projects that keep running and need someone to stay on top of them. For me the tradeoff is personal rather than technical: it is worth arranging the setup around your own routine, so that staying informed does not cost the time you want for rest.

A useful next test would record the plan, the telemetry tools connected, the alert source, how long the first investigation took, the ACUs it used, and whether the proposed root cause held up.