Diagnosis engine

A written brief on every incident, by the time you reach the laptop.

The diagnosis engine reads telemetry, system events, and recent changes the moment an alert fires. It produces a short engineering brief — what broke, the most likely cause, and the first three things worth trying — and attaches it to the incident before the page reaches your phone.

Start free trial

Read the documentation

Pulsewise AI● CRITICAL

3m ago

Memory leak detectedprod-api-01 · nginx-proxy · +480MB / 2h

ROOT CAUSE

Memory on prod-api-01 grew 480MB in 2h. Correlates with deploy v3.1.7 at 09:15 UTC. Worker process is leaking upstream connections on client disconnect.

SUGGESTED FIXnginx.conf

// add upstream keepalive + reload
proxy_read_timeout 30s;
proxy_send_timeout 30s;
systemctl reload nginx

View incidentTimeline

CAPACITY

Disk filling fast

prod-db-01 growing 2.1 GB/day. 90% in 8 days.

● WAL files

PERFORMANCE

Response degraded

staging-api-02 jumped 120ms → 890ms after deploy.

● N+1 query

PATTERN

Recurring OOM kill

redis-cache OOM × 3 this week, peak 18–20 UTC.

● 256MB → 512MB

Pipeline

Four stages between the threshold and the page.

Most monitoring stops at “something crossed a line.” This pipeline begins there — joining signal, attribution, and prose into a single readable brief that lands with the alert.

Telemetry capture

The agent streams CPU, memory, disk, network, and service-state telemetry continuously — at the resolution your plan allows.

Causal join

When a threshold trips, the engine pulls the surrounding metric window, recent system events, and any deploys or config changes that touched the host.

Brief generation

A written incident brief is produced: what failed, the most plausible cause, and the first three actions to try, ranked by impact.

Routed delivery

The brief is delivered to the channel the responsible team reads — Slack thread, Discord embed, email, or signed webhook — with the full incident attached.

What it produces

What lands in the channel when the page fires.

Causal correlation

Metrics, system events, service state, and recent changes are joined into a single causal chain — no separate query language required.

Written engineering brief

A two-paragraph summary in the prose an on-call engineer would actually write, attached to the incident the moment it opens.

Three-step playbook

Concrete first actions ranked by likelihood of resolving the incident — restart, reclaim, investigate, escalate.

Deploy and config attribution

Cross-references recent commits, package updates, and cron windows that line up with the failure timestamp.

Triage-ready severity

Each incident is graded so the queue remains sortable when several fire inside the same window.

Sample briefs

Three real incidents, three real briefs.

Reproduced from production hosts, with identifiers redacted. This is the quality and tone of brief that arrives with every alert.

CRITICAL

OOM kill on db-prod-01 (postgres, PID 4128)

Postgres was reaped by the OOM killer at 03:42 UTC after RSS climbed past 95% of system memory and held there for twelve minutes. Two signals line up: a long-running analytical query opened against the reporting schema at 03:31, and the API connection pool jumped from a steady 80 to 240 over the next eight minutes — likely a retry storm following an upstream timeout.

Suggested first actions

Restart postgresql.service and confirm shared_buffers settles
Pull the slow-query log for 03:30–03:42 UTC and identify the analytical query owner
Cap pgbouncer pool_size or tune work_mem before the next reporting window

WARNING

Disk pressure on web-03, /var/log at 87%

/var/log climbed past 87% and is trending toward the 90% page threshold within roughly six hours at the current ingestion rate. logrotate ran at 02:00 but appears to have skipped the nginx access logs — the rotation policy points at a path that no longer exists after last week’s nginx upgrade.

Suggested first actions

Run logrotate -f /etc/logrotate.d/nginx and confirm rotation completes
Update the rotation glob to match the current nginx access log path
Consider mounting /var/log on its own volume before the next upgrade window

INFO

Periodic CPU saturation on worker-02 during nightly export

CPU sat at 92% between 02:00 and 02:15 UTC, coinciding with the export-reports cron job. The same shape has repeated nightly for seven days with no downstream impact and no growth in duration. Recording for context, not paging.

Suggested first actions

No action required at this time
If the window starts to expand, move the job to 04:00 UTC
Track total runtime against the seven-day baseline

What changes for the team that runs the pager.

MTTR collapses

Most of an incident’s first hour is spent reconstructing context. The brief delivers it before the laptop is open.

Tier-1 stays tier-1

Junior engineers resolve their share of incidents because the playbook arrives with the page, not after escalation.

Patterns become visible

Recurrence detection surfaces the hosts and services that quietly dominate the postmortem queue.

A written brief on every incident, by the time you reach the laptop.

Four stages between the threshold and the page.

Telemetry capture

Causal join

Brief generation

Routed delivery

What lands in the channel when the page fires.

Causal correlation

Written engineering brief

Drift and regression detection

Three-step playbook

Deploy and config attribution

Triage-ready severity

Three real incidents, three real briefs.

OOM kill on db-prod-01 (postgres, PID 4128)

Disk pressure on web-03, /var/log at 87%

Periodic CPU saturation on worker-02 during nightly export

What changes for the team that runs the pager.

MTTR collapses

Tier-1 stays tier-1

Patterns become visible

Get started in under a minute.