Skip to main content

​
Not a rulebook

Automation in a traditional paging tool is deterministic. You author the mapping from alert to action — if this alert fires, run this check, notify that group — and then you maintain it as the system changes. The automation is only ever as good as the scenarios someone thought to write down, and it goes stale the moment the architecture moves underneath it. WHAWIT’s on-call is agentic. A standing team of AI agents works each incident the way people would: looking at something, forming a view, and choosing what to look at next based on what they just found. There is no decision tree to author, no runbook to keep current, and no alert-to-action mapping to maintain. You configure who is on call and how escalation should reach them. You do not have to encode how to investigate.
This is the part that does not transfer from PagerDuty or Opsgenie, because there is nothing to transfer. The rules you maintain there have no equivalent here — the agents work without them.

​
The team

Five specialist roles, each with its own remit and its own tools: Agents have reporting lines and peers, so the commander can direct the specialists and the specialists can hand findings to each other rather than each working in isolation.

​
What they can reach for

Each agent is granted a set of tools appropriate to its role. Across the team:

Query logs

Run targeted queries against your connected log providers.

Group errors

Cluster related errors so one underlying fault is not read as many.

Search your repository

Look into the GitHub repository behind the failing service, including recent changes.

Search the knowledge base

Check what previous incidents established about this system.

Analyze context

Correlate signals across providers into a single picture.

Open and update incidents

Create the incident, revise its severity, record the timeline.

Notify responders

Reach people over the escalation policy’s channels.

Attempt recovery

Where a failure is of a kind that can be retried safely, retry it.

​
It never rests

The team does not only react to a page.
  • It runs on a cycle, working continuously rather than waiting to be summoned.
  • It triggers immediately when an alert fires, rather than waiting for the next cycle.
  • It schedules its own follow-ups — if something needs checking again in ten minutes, the team queues that itself.
  • The cycle tightens while an incident is live, so an active problem is looked at more often than a quiet system.
The practical consequence is that by the time a human is paged, work has already happened. And if nobody acknowledges, the work keeps happening.

​
It learns your systems

The Knowledge Engineer writes back what each incident established. Recurring failures are met with what the previous occurrence cost you to learn, rather than being investigated from scratch every time.
This compounds in a way rule-based automation does not. A runbook captures what someone knew when they wrote it. A knowledge base that the agents both read and write captures what the system has actually done since.

​
Configuration and control

An agent team is attached to an on-call agent and switched on with a single control: Enable AI Agent Team, in the agent’s editor. With the team on, the agent’s cadence becomes adaptive and coordinator-driven — the team’s coordinator decides when the next cycle runs, checking more often during active incidents and backing off when the system is healthy, and critical findings trigger immediate follow-up cycles. The agent’s card reflects this, showing Adaptive · coordinator-driven instead of a fixed interval.
Autonomous agents can also be disabled organization-wide by an operator without touching any monitoring configuration. If you need the agents to stop — during a maintenance window, or while diagnosing unexpected behaviour — that switch exists and takes effect on the next cycle.

On-call overview

How a page happens, end to end.

Native, not integrated

Why the paging and the investigation live in the same product.