incident intelligence

Outagesdon’tstartwherethey hurt.

Checkout pages at 4 seconds. The cause was a connection pool three services upstream, eleven minutes earlier. Forge maps that chain the first time it happens — and recognises it the next time, before the page fires.

See it work

no agent to install · one webhook · 5-minute setup

evidence · 2,481 lines3 that matter
02:8:00checkout-webINFOGET /cart/items 200 34ms
02:9:07auth-svcINFOtoken refresh ok sub=u_9241
02:10:14payments-apiINFOcharge.authorized amt=4200 cur=usd
02:11:21edge-gatewayINFOupstream healthy 6/6
02:12:28cache-clusterINFOevicted 128 keys lru
02:13:35sessions-dbINFOcheckpoint complete lsn=0/3A1F
02:8:42checkout-webINFOPOST /cart/apply-coupon 200 51ms
02:9:49auth-svcWARNretry attempt 1/3 upstream=sessions-db
02:10:56payments-apiINFOwebhook delivered stripe 200
02:11:03edge-gatewayINFOtls handshake resumed 0-rtt
02:12:10cache-clusterWARNhit ratio 0.71 below target 0.85
02:13:17sessions-dbINFOvacuum analyze sessions 1.2s
02:8:24checkout-webINFOGET /checkout 200 88ms
root cause10m 55s before the page
auth-svc pool exhaustion→sessions-db failover→checkout p99
ingests from
DatadogGrafanaCloudWatchPagerDutySentryPrometheusOpsgenieKubernetes eventsAny webhook
01how it works

Forty seconds, end to end.

From the alert firing to a written root cause — and to the memory that makes the next one shorter. No agent, no query language, no dashboard to babysit.

  1. t+0ms01

    A signal arrives

    Datadog, Sentry, a cron job with curl — anything that can POST JSON hits one signed endpoint. Nothing is deployed inside your cluster.

    POST /ingest · 202 accepted
  2. t+40ms02

    Triage decides

    The signal is scored, deduplicated against what's already open, and either escalated or suppressed. Suppressed does not mean deleted — every call stays on the record, labelled and reversible.

    1,247 in · 3 escalated
  3. t+38s03

    The analysis is written

    Forge walks the dependency graph backwards from the symptom, reads the evidence, and writes a causal chain with a severity call and a confidence number attached.

    root cause · 91% confidence
  4. after04

    It becomes memory

    The cascade strengthens your topology, the fix that worked is promoted in the runbook ranking, and the write-up is embedded for the copilot to cite. The next occurrence starts from here.

    graph +1 edge · runbook rescored
02triage

Most of what pages you is not an incident.

Forge scores every signal on arrival, collapses the duplicates and opens an incident only for what survives. The suppressed ones are not deleted — they stay on the record, labelled and reviewable, because a filter nobody can inspect is a filter nobody can trust.

1,247 signals in3 incidents opened

Every bar is a real signal. The three lit ones became incidents; the rest are one click away in the suppression audit.

SEV-1INC-2291 · 40s ago

Checkout latency above 4s at p99

91%
confidence
root cause
auth-svc 4d1c9→pool exhaustion→sessions-db failover→checkout p99
ranked remediation
01Fail checkout writes to the read replica94
02Drain the auth-svc connection pool81
03Roll back auth-svc to build 4d1c963
03analysis

A root cause you can argue with.

Every incident gets a written analysis: the causal chain, a severity call, and a confidence score attached to it. When Forge is unsure it says so, in a number — because a verdict you cannot challenge is worth less at 3am than an honest maybe.

04memory

The part that compounds.

Any tool can tell you something broke. What makes the second year quieter than the first is a system that remembers every failure it has already explained.

Topology

Failures are edges, not dots. Every cascade Forge sees strengthens the graph, until the single point of failure in your estate is something you can point at on a screen.

Knowledge

Runbooks, architecture notes and post-mortems — chunked, embedded, reranked. The copilot answers from your own documents, and cites which one.

Runbooks

Remediation steps scored and deduplicated across every analysis, so the fix that actually worked last time is the one at the top of the list.

security posture

Your telemetry is the most sensitive thing you own.

Forge is built to be trusted with production logs by teams who are not allowed to hand them over.

Evidence stays encrypted

Sensitive logs can be uploaded as TFHE ciphertext and scored homomorphically. The server never holds the plaintext — not in memory, not at rest.

Signed ingest, rotatable

Every payload carries an HMAC signature. Keys are scoped per organisation and rotate from the dashboard without redeploying anything.

Role-scoped access

Credentials, member management and destructive actions sit behind explicit role ranks, enforced server-side rather than hidden in the UI.

Nothing dropped silently

Every suppressed signal keeps its score and its reason. The triage threshold is calibrated against labelled outcomes you can audit and disagree with.

05connect

One endpoint. No agent.

Point anything that can POST JSON at a single signed URL — your existing alerting, a Lambda, a cron job with curl. Forge takes it from there. Nothing to deploy inside your cluster.

connect.sh
curl -X POST https://api.forge.dev/ingest \
-H 'x-forge-signature: $FORGE_KEY' \
-d '{
"source": "datadog",
"service": "checkout-web",
"message": "p99 latency 4.2s",
"severity": "warning"
}'
202 accepted · triage scored in 40ms

Your next outage is already in the graph.

Connect one alert source. Forge starts learning your failure modes on the very first incident.