Seer

Learn more about Sentry's integration platform Seer webhooks for Issue Fix analysis notifications.

Sentry integrations that have subscribed to Seer webhooks can receive notifications about the Seer Autofix process. These webhooks allow you to track the progress of root cause analysis, solution generation, and code fixes.

'Sentry-Hook-Resource': 'seer'

Seer webhooks support seven different event types that track the complete lifecycle of AI-powered issue resolution:

  • seer.root_cause_started - Triggered when root cause analysis begins
  • seer.root_cause_completed - Triggered when root cause analysis completes with results

  • seer.solution_started - Triggered when solution generation begins
  • seer.solution_completed - Triggered when a solution has been generated

  • seer.coding_started - Triggered when the coding step (code fix generation) begins
  • seer.coding_completed - Triggered when code changes are ready
  • seer.pr_created - Triggered when pull request(s) are created

All Seer webhooks share these common attributes:

  • type: string
  • description: The specific Seer event that occurred (e.g., root_cause_started, solution_completed)

  • type: integer
  • description: Unique identifier for this Seer analysis run

  • type: integer
  • description: The Sentry issue ID being analyzed

Minimal payload indicating analysis has begun:

Copied
{
  "action": "root_cause_started",
  "actor": {
    "id": "sentry",
    "name": "Sentry",
    "type": "application"
  },
  "data": {
    "run_id": 12345,
    "group_id": 1170820242
  },
  "installation": {
    "uuid": "a8e5d37a-696c-4c54-adb5-b3f28d64c7de"
  }
}

Includes the identified root cause. The root_cause object contains:

  • one_line_description (string): A one-sentence summary of the root cause.
  • five_whys (array of strings): A chain of reasoning explaining why the issue occurred.
  • reproduction_steps (array of strings): Steps to reproduce the issue.
  • relevant_repo (string): The repository most relevant to the root cause, in owner/name format.
Copied
{
  "action": "root_cause_completed",
  "actor": {
    "id": "sentry",
    "name": "Sentry",
    "type": "application"
  },
  "data": {
    "run_id": 12345,
    "group_id": 1170820242,
    "root_cause": {
      "one_line_description": "A `TypeError` is thrown in `sendWelcomeEmail` because `getUser` can return `null`, but the result is used without a null check.",
      "five_whys": [
        "The error `TypeError: Cannot read properties of null (reading 'email')` is raised at runtime.",
        "The `user` object is `null` when `user.email` is accessed.",
        "`getUser(userId)` returns `null` when no matching user exists.",
        "`sendWelcomeEmail` assumes `getUser` always returns a user and omits a null check."
      ],
      "reproduction_steps": [
        "Call `sendWelcomeEmail` with a `userId` that does not exist.",
        "Observe the `TypeError` raised when `user.email` is accessed."
      ],
      "relevant_repo": "owner/repo"
    }
  },
  "installation": {
    "uuid": "a8e5d37a-696c-4c54-adb5-b3f28d64c7de"
  }
}

Minimal payload indicating solution generation has begun:

Copied
{
  "action": "solution_started",
  "actor": {
    "id": "sentry",
    "name": "Sentry",
    "type": "application"
  },
  "data": {
    "run_id": 12345,
    "group_id": 1170820242
  },
  "installation": {
    "uuid": "a8e5d37a-696c-4c54-adb5-b3f28d64c7de"
  }
}

Includes the generated solution details. The solution object contains:

  • one_line_summary (string): A one-sentence summary of the proposed fix.
  • steps (array): The ordered steps to implement the solution. Each step has a title and a description.
Copied
{
  "action": "solution_completed",
  "actor": {
    "id": "sentry",
    "name": "Sentry",
    "type": "application"
  },
  "data": {
    "run_id": 12345,
    "group_id": 1170820242,
    "solution": {
      "one_line_summary": "Guard against a missing user in `sendWelcomeEmail` by returning early when `getUser` returns `null`.",
      "steps": [
        {
          "title": "Add a null check",
          "description": "In `notifications.js`, check whether `user` is defined after calling `getUser(userId)` and return early if it is not."
        },
        {
          "title": "Log the missing user",
          "description": "Emit a warning when no user is found so the missing record can be investigated."
        }
      ]
    }
  },
  "installation": {
    "uuid": "a8e5d37a-696c-4c54-adb5-b3f28d64c7de"
  }
}

Minimal payload indicating the coding step has begun:

Copied
{
  "action": "coding_started",
  "actor": {
    "id": "sentry",
    "name": "Sentry",
    "type": "application"
  },
  "data": {
    "run_id": 12345,
    "group_id": 1170820242
  },
  "installation": {
    "uuid": "a8e5d37a-696c-4c54-adb5-b3f28d64c7de"
  }
}

Includes the code changes made. code_changes is an object keyed by repository name (in owner/name format); each value is a list of file-level changes. Each change has:

  • diff (string): The unified diff for the file.
  • path (string): The path of the changed file.
  • type (string): The kind of change — M (modified), A (added), or D (deleted).
  • added (integer): The number of lines added.
  • removed (integer): The number of lines removed.
Copied
{
  "action": "coding_completed",
  "actor": {
    "id": "sentry",
    "name": "Sentry",
    "type": "application"
  },
  "data": {
    "run_id": 12345,
    "group_id": 1170820242,
    "code_changes": {
      "owner/repo": [
        {
          "diff": "--- notifications.js\n+++ notifications.js\n@@ -8,3 +8,7 @@\n   const user = getUser(userId);\n+  if (!user) {\n+    logger.warn(`No user found for id: ${userId}`);\n+    return;\n+  }\n   sendEmail(user.email, \"Welcome!\");\n }",
          "path": "notifications.js",
          "type": "M",
          "added": 4,
          "removed": 0
        }
      ]
    }
  },
  "installation": {
    "uuid": "a8e5d37a-696c-4c54-adb5-b3f28d64c7de"
  }
}

Includes pull request details, there may be more than one pull request if there are multiple repos:

Copied
{
  "action": "pr_created",
  "actor": {
    "id": "sentry",
    "name": "Sentry",
    "type": "application"
  },
  "data": {
    "run_id": 12345,
    "group_id": 1170820242,
    "pull_requests": [
      {
        "pull_request": {
          "pr_number": 123,
          "pr_url": "https://github.com/owner/repo/pull/123",
          "pr_id": 456789
        },
        "repo_name": "my-app",
        "provider": "unknown"
      }
    ]
  },
  "installation": {
    "uuid": "a8e5d37a-696c-4c54-adb5-b3f28d64c7de"
  }
}

Seer webhooks enable you to:

  1. Track Progress: Monitor the status of Seer Issue Fix in real-time
  2. Build Notifications: Send custom notifications when fixes are ready
  3. Audit Trail: Maintain a log of all Seer fixes for your issues
  4. Custom Integrations: Build custom tools that react to Seer's analysis results

  • Store the run_id to correlate related webhook events
  • Use the group_id to link webhooks back to the original Sentry issue
Previous
Errors
Next
Preprod Artifacts
Was this helpful?
Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").