Skip to main content

Change Intelligence

Most incidents are caused by a change. InfraSage treats change events (deploys, config edits, feature flags, scale events, migrations) as first-class telemetry and guarantees they reach every root-cause analysis.

Getting changes in​

For deploys, point your CI at the deploy endpoints and every release lands automatically:

POST /api/v1/deploys/github     (GitHub Actions / webhook payload)
POST /api/v1/deploys/gitlab
POST /api/v1/deploys/manual

For everything that isn't a deploy, there is a generic change API:

curl -X POST https://api.infrasage.dev/api/v1/changes \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{
    "service_id": "payment-service",
    "kind": "config",            # deploy | config | flag | scale | migration
    "version": "pool-size-50",
    "ref": "CHG-1042",
    "summary": "raised db pool from 20 to 50",
    "actor": "alice"
  }'

Service ids are tenant-qualified automatically. Send the bare name your service reports and the platform stores it correctly for attribution.

Code context: deploy diff packs​

A version string tells RCA that something changed; the diff tells it what. When a change event carries a repository and commit range, InfraSage indexes a diff pack at deploy time, so code context at RCA time is pure retrieval: a few hundred prompt tokens instead of an LLM reading a diff on every analysis.

Turn it on by setting a read-only GitHub token on the engine and sending the extra fields:

GITHUB_CODEINTEL_TOKEN=<fine-grained PAT with repo read>
{
  "service_id": "payment-service",
  "kind": "deploy",
  "version": "v2.14.1",
  "repo": "acme/payment-service",
  "base_ref": "v2.14.0",
  "head_ref": "v2.14.1"
}

Each pack distills the compare view into:

  • the file inventory (paths, adds/deletes)
  • verbatim hunks for config and infra files (k8s, helm, terraform, env, flags), because pool_size: 50→10 is the root-cause gold and needs zero AI to extract
  • risk tags for the failure classes the diff touches: connection-pool, timeouts, retries, database, caching, concurrency, feature-flags, resources

RCA prompts then carry a compact CODE CONTEXT block for the service's recent deploys, listing files, risk tags, and the config hunks, with the instruction to cite paths and keys that plausibly explain the anomaly. Indexing is asynchronous and per-deploy, so analyses never wait on GitHub.

Where changes show up​

Changes in the blast window appear on the incident timeline alongside alerts, so "deploy at 14:02, alert at 14:07" is visible without asking.

Every RCA gets them too, and not at the AI's discretion. The analysis prompt always includes the service's changes from 60 minutes before onset through 5 minutes after, with an explicit instruction to cite the version when a change plausibly explains the anomaly. It is injected, not looked up. In verified control runs, a deploy landing five minutes before a fault is named in the analysis by version.

Detection baselines can also be made deploy-aware (optional, DEPLOY_AWARE_BASELINE_ENABLED): samples taken immediately after a deploy are excluded, so a deliberate performance change doesn't poison the statistics it will be judged against.

The quiet side​

Change intelligence also has to not cry wolf: a deploy with no behavioral delta must produce no page. The false-positive control scenario (innocent deploy, 15-minute watch) runs as a regression gate on exactly this.

:::tip Roadmap The next layer is code-level context: connecting a repository so deploys carry their commit range, config-key diffs, and touched symbols into the RCA evidence pack, indexed offline so analysis-time cost stays near zero. Design in progress. :::