# Agent Skill Source: https://docs.steadwing.com/ai-skills Install the Steadwing Agent Skill so Claude Code, Cursor, and other coding agents can self-register and run root cause analysis the moment a production error appears **no API key to paste, no manual setup**. ## What is the Steadwing Agent Skill? An Agent Skill is a folder of instructions and scripts that a coding agent discovers and uses on its own **no prompting required**. The Steadwing Agent Skill teaches your agent how to register with Steadwing, watch for production-style errors, and trigger root cause analysis automatically. Drop it in once and your agent goes from "writes code" to "investigates incidents." Unlike the [MCP Server](/steadwing-mcp), the skill is **self-onboarding**: the first time it runs, it registers an agent for you and stores a key locally. There's nothing to paste and nothing to configure. The agent registers itself on first use and stores its own API key, no signup flow Optionally watches your agent's output for tracebacks and offers to run RCA Add the skill with a single command in Claude Code, Cursor, or Windsurf Sends only the source files named in the stack trace for accurate analysis ## How do I install the Agent Skill? Install the skill with the [`skills`](https://skills.sh) CLI: ```bash theme={null} npx skills add steadwing/agent-skills ``` To install only the Steadwing skill from the collection: ```bash theme={null} npx skills add steadwing/agent-skills --skill steadwing ``` Add `--global` to make the skill available across all of your projects: ```bash theme={null} npx skills add steadwing/agent-skills --global ``` **Using Claude Code?** You can install the skill as a plugin instead. Add the marketplace, then install the plugin: ```bash theme={null} /plugin marketplace add steadwing/agent-skills /plugin install steadwing@steadwing-agent-skills ``` The skill works with any agent that supports the open skills format, including Claude Code, Cursor, and Windsurf. The agent auto-detects which environment it's running in during registration. The Steadwing Agent Skill is open source. View the code, report issues, or contribute at [github.com/steadwing/agent-skills](https://github.com/steadwing/agent-skills). ## How does the skill work? Run `npx skills add steadwing/agent-skills` in your project. Your agent picks it up automatically. The first time the skill runs, your agent calls Steadwing to register itself, then writes its credentials to `~/.steadwing/credentials.json`. **No API key to paste**. The skill prints a claim URL. Open it to link the agent to your Steadwing account and keep it from expiring. Ask your agent to investigate an error or let auto-detection offer it for you. Steadwing runs the analysis in the background and returns a link to the full report. ## How do I claim an agent? When the skill registers, it creates an **unclaimed** agent that expires in **3 days**. To keep it and link it to your organization, open the claim URL the skill prints after registration: ```text theme={null} https://app.steadwing.com/login?claim= ``` Claiming an agent associates it with your account so it inherits your connected integrations and never expires. You can check an agent's status, including time remaining before expiry, from the [Dashboard](https://app.steadwing.com). Claim your agent right after the first registration. Once claimed, every RCA it triggers can pull from your connected GitHub, Datadog, Sentry, and other integrations for deeper analysis. ## How do I use the skill for debugging? ### Investigate an error on demand Paste a stack trace and ask your agent to look into it: ```text theme={null} "Run RCA on this error: ConnectionTimeout in PaymentService.processOrder()" ``` The skill reads the files named in the trace, attaches them, and triggers analysis. Steadwing correlates the error with logs, metrics, and recent code changes, then returns the root cause with a suggested fix. ### Let auto-detection catch errors for you Opt in to auto-detection and the skill installs a hook that watches your agent's tool output. When a production-style error appears an unhandled exception, a traceback, a failed deploy the skill surfaces it and offers to run RCA. Auto-detection only **detects** and **asks**. The skill never sends anything to Steadwing without your confirmation — you're always in control of what gets analyzed. To remove auto-detection later, delete the Steadwing entry under `hooks.PostToolUse` in your agent's settings. ## How do integrations improve results? The skill triggers the same analysis engine as the rest of Steadwing, so results get richer as you connect more tools to your account: | Integration | What It Adds | | --------------------- | ------------------------------------------------------ | | **GitHub** | Repository context, recent commits, deployment history | | **Datadog / Grafana** | Metrics, monitors, and APM data | | **Sentry** | Error tracking and stack traces | | **AWS / GCP** | Cloud resource and service insights | Connect integrations at [app.steadwing.com/integrations](https://app.steadwing.com/integrations) to unlock full investigation capabilities. ## FAQs No. The skill registers an agent for you automatically on first use there's no signup flow and no API key to paste. To keep the agent past 3 days, claim it via the URL the skill prints after registering. The skill writes them to `~/.steadwing/credentials.json` (or `%APPDATA%\steadwing\credentials.json` on Windows) with owner-only permissions. They're never committed to your repo. Unclaimed agents expire after 3 days. If the key is revoked or expired, the skill detects it on the next call, re-registers automatically, and lets you know. Claim the agent to prevent expiry entirely. Only files explicitly attached to an RCA request are sent typically the handful named in the stack trace. Auto-detection never sends anything without your confirmation. The [MCP Server](/steadwing-mcp) exposes a `run_rca` tool you invoke from your IDE and requires an API key from your account. The Agent Skill is self-onboarding and it registers its own agent and can watch for errors proactively. Use the skill for hands-off, zero-setup RCA; use MCP when you want explicit tool control. Need help? Contact us at [hello@steadwing.com](mailto:hello@steadwing.com) # Claim Agent Source: https://docs.steadwing.com/api-reference/agents/claim POST /api/agents/claim Claim an existing agent by associating it with your organization. # Register Agent Source: https://docs.steadwing.com/api-reference/agents/register POST /api/agents/register Register a new Steadwing agent instance for autonomous incident response. # Get Agent Status Source: https://docs.steadwing.com/api-reference/agents/status GET /api/agents/status Retrieve the current status of a registered agent. # Analyze via MCP Source: https://docs.steadwing.com/api-reference/mcp/analyze POST /api/mcp/analyze Trigger incident analysis via MCP (Model Context Protocol) integration. # Changelog & Release Notes Source: https://docs.steadwing.com/changelog Latest updates, new integrations, and platform improvements * Added GitLab integration for code change tracking, merge request analysis, and CI/CD pipeline monitoring * Added Supabase integration for database health monitoring * Added Vercel integration for deployment and serverless function monitoring * Prompts updates for robust tool calling # Your Autonomous On-Call Engineer Source: https://docs.steadwing.com/index Steadwing diagnoses issues instantly, correlates evidence across your stack, and resolves them - so your team can ship, not firefight. Steadwing dashboard showing an automated root cause analysis report with evidence from logs, metrics, and code changes correlated across multiple data sources, alongside suggested short-term and long-term remediation actions. ## How does Steadwing resolve incidents? Steadwing diagnoses issues instantly, correlates evidence across your stack, and resolves them - so your team can ship, not firefight. When production breaks, your team typically scrambles across Slack, Datadog, GitHub, and a dozen other tools piecing together what went wrong. Steadwing does that in seconds. While you're still context-switching between dashboards, Steadwing has already correlated 20+ data sources and identified the problem. ## What can Steadwing do? Root cause in under 5 mins with evidence from logs, metrics, traces, and code. Not guesswork. PRs, rollbacks, config changes - approve or auto-execute. Real fixes, not suggestions. 47 alerts. 1 incident. Groups related alerts and separates root cause from symptoms. Ask follow-up questions about any incident. An AI SRE teammate that knows your stack. Pulls from observability, code, communication, and incident management tools at once. Every incident makes the next one faster. Learns from history - accuracy improves over time. ## How does it work step by step? Integrate in minutes with OAuth. Steadwing pulls context from Datadog, PagerDuty, Slack, GitHub, and more. No agents to deploy, no code changes required. When incidents hit, Steadwing correlates all data sources to identify root cause - with evidence. Watch sections appear as evidence is gathered in real-time. Get actionable solutions - short-term fixes stop the bleeding, long-term fixes solve it for good. Approve and resolve, or configure auto-execute for low-risk actions. ## What This Looks Like in Practice ### The 2am Page Alert fires. You wake up, open laptop, check Datadog. Metrics look weird. Open GitHub - was there a deploy? Check Slack - who's awake? **45 minutes later**, you've found the bad config change. Alert fires. Steadwing has already posted: "Root cause: Config change in PR #312 reduced connection pool size. Rollback ready." You approve from your phone. **Back to sleep in 3 minutes.** **MTTR: 3 minutes** vs. typical 45+ minutes ### The Cascading Failure Database hiccup triggers **40+ alerts** across 8 services. PagerDuty is chaos. Three engineers spend an hour figuring out it's all the same root cause. 40 alerts arrive. Steadwing groups them into **1 incident**, identifies the database as root cause, shows which failures are symptoms. One engineer resolves it in **10 minutes**. **MTTR: 10 minutes.** 3 engineers freed up to work on other things. ## Why Teams Choose Steadwing Bring services back up in minutes instead of hours. No more debugging across teams in meetings. Let your team focus on building features and shipping products, not chasing alerts. 20+ integrations with tools you already use. Connect in minutes, not weeks. OAuth setup, no complex configuration. Most teams are live within minutes of signing up. ## What tools does Steadwing integrate with? Steadwing connects to 20+ tools across your existing stack: | Category | Tools | | ------------------ | ------------------------------------------------------ | | **Alerting** | PagerDuty, Datadog, New Relic, Grafana, GCP | | **Observability** | Datadog, SigNoz, Elasticsearch, Mezmo, Grafana, Sentry | | **Code** | GitHub, Linear | | **Communication** | Slack | | **Infrastructure** | Kubernetes, AWS CloudWatch, GCP | Integrate in minutes. No agents to deploy. No code changes required. See the full list of [integrations](/integrations). ## What is included in every RCA report? Each root cause analysis from Steadwing includes: * **Root Cause Summary** - Plain-language explanation of what went wrong and why * **Evidence** - Logs, metrics, and traces that support the diagnosis with source attribution * **Timeline** - Sequence of events leading to the incident * **Impact Assessment** - Severity, affected systems, and blast radius * **Short-term Solutions** - Quick hotfixes to bring systems back up immediately * **Long-term Solutions** - Permanent fixes that solve the issue for good * **Confidence Score** - Tells you when to trust it vs. dig deeper ## Ready to Get Started? 1. [Sign up](https://app.steadwing.com) with your Google account 2. Connect your integrations in [Settings](https://app.steadwing.com/settings) 3. Trigger RCA from Slack, Linear, or paste any error directly Free tier available. No credit card required. Connect your stack in 5 minutes. Step-by-step setup instructions to connect your tools Learn how integrations power root cause analysis # Integrations Source: https://docs.steadwing.com/integrations Connect Steadwing to 20+ tools including Slack, GitHub, Datadog, Sentry, PagerDuty, AWS, and Kubernetes. Steadwing automatically pulls and correlates logs, metrics, traces, and code changes during root cause analysis. ## Why do integrations matter for root cause analysis? Steadwing integrations automatically pull data from all your connected tools and correlate logs, metrics, traces, and code changes in real-time. When an incident occurs, Steadwing queries all connected sources in parallel — eliminating the manual context switching between Datadog, GitHub, Slack, and other dashboards that typically consumes 80% of incident response time. ## How do integrations power root cause analysis? Steadwing's AI correlates data from multiple sources simultaneously to identify root causes that would take humans hours to find manually. Reduce MTTR by eliminating manual log searches and metric lookups. Steadwing queries all your tools in parallel during analysis. AI identifies patterns across logs, metrics, code changes, and deployments that humans often miss when investigating separately. Every RCA includes evidence from all connected tools - no more switching between dashboards to piece together what happened. Each incident improves Steadwing's understanding of your system, making future analyses faster and more accurate. ## What data does Steadwing correlate during RCA? During root cause analysis, Steadwing automatically pulls and correlates: | Data Type | What Steadwing Looks For | Example Sources | | --------------------- | -------------------------------------------------- | --------------------------------------------------- | | **Logs** | Error messages, stack traces, anomalies | CloudWatch, GCP, Elasticsearch, Mezmo, Scalyr, Loki | | **Metrics** | Performance degradation, resource spikes | Datadog, New Relic, Prometheus, SigNoz | | **Errors** | Exceptions, crash reports, error rates | Sentry | | **Traces** | Request flows, latency bottlenecks | GCP Cloud Trace, SigNoz | | **Code Changes** | Recent commits, deployments, releases | GitHub, GitLab | | **CI/CD Pipelines** | Pipeline failures, build status, deployment events | GitLab, Vercel | | **Infrastructure** | Pod status, cluster events, resource usage | Kubernetes, AWS, GCP | | **Sandbox Execution** | Sandbox logs, lifecycle events, resource metrics | E2B | | **Deployments** | Build status, serverless functions, edge config | Vercel | | **Alerts** | Triggered monitors, alarm states | Datadog, CloudWatch, SigNoz | | **Incidents** | Incident timelines, escalations, response metrics | PagerDuty, Better Stack | | **Uptime** | Monitor states, response times, heartbeat status | Better Stack | | **Network** | DNS records, WAF rules, firewall events | Cloudflare | ## How does the RCA process work with integrations? 1. **Alert Received** - An incident is triggered via Slack, Linear, or your monitoring tools 2. **Data Collection** - Steadwing queries all connected integrations for relevant data around the incident timeframe 3. **Signal Correlation** - AI analyzes logs, metrics, errors, and code changes together to find patterns 4. **Root Cause Identification** - Steadwing identifies the most likely cause with supporting evidence from multiple sources 5. **Solution Proposal** - Actionable remediation steps are suggested based on the identified root cause You can give Steadwing infrastructure context — like service names, team ownership, and known dependencies — using [Custom Instructions](#custom-instructions) at the organization level. This helps the RCA orchestrator gather more targeted evidence across all your integrations. ## What integration categories does Steadwing support? Steadwing supports integrations across your entire stack: * **Communication** - Receive alerts and trigger RCA directly from Slack * **Issue Tracking** - Analyze issues assigned in Linear automatically * **Incident Management** - Pull incident timelines, alerts, and response metrics from PagerDuty * **Code & Deployments** - Correlate incidents with recent GitHub and GitLab commits, merge requests, and releases * **CI/CD Pipelines** - Monitor GitLab pipeline failures and deployment events * **Uptime & On-Call** - Pull monitor states, heartbeat status, and on-call schedules from Better Stack * **Observability** - Query metrics and APM data from Datadog, New Relic, SigNoz, and Grafana * **Error Tracking** - Pull error details and stack traces from Sentry * **Logging** - Search logs from Elasticsearch, Mezmo, Scalyr, CloudWatch, and GCP * **Infrastructure** - Monitor Kubernetes clusters, AWS, GCP, Cloudflare, Supabase, Vercel, and E2B ## How do I get started with integrations? 1. Navigate to [Settings](https://app.steadwing.com/settings) in your Steadwing dashboard 2. Connect the integrations relevant to your stack 3. Start triggering RCA from Slack or Linear - Steadwing handles the rest **Start with the basics**: Connect Slack + GitHub or GitLab + your primary observability tool (Datadog, New Relic, or Sentry) to get immediate value. Add more integrations as needed. ## How do I configure custom instructions for RCA? Custom instructions let you provide additional context to Steadwing's RCA analysis, helping the AI gather more relevant evidence from your specific environment. Custom instructions are available at two levels — organization-wide and per-integration. You can configure custom instructions from [Settings](https://app.steadwing.com/settings) in your Steadwing dashboard. Only organization owners can update custom instructions. Any member can view them. ### Organization-Level Organization-level instructions are applied to the main RCA orchestrator prompt. Use these to describe broad context about your system — service architecture, team ownership, naming conventions, or known dependencies. **Examples:** * *"Our payment service is called billing-core and lives in the payments repo"* * *"Deployments happen via GitHub Actions — check the deploy-prod workflow for recent runs"* ### Integration-Level Integration-level instructions are applied to the specific subagent prompt for that integration (e.g., Datadog, Sentry, GitHub). Use these for platform-specific context like log group names, dashboard IDs, repository mappings, or query filters. **Examples:** * *"Always check the prod-alerts Datadog dashboard for latency spikes"* * *"Our Sentry org slug is acme-corp and errors are tagged by team with `team:platform`"* ## Need Help? If you encounter any issues during setup, contact us at [hello@steadwing.com](mailto:hello@steadwing.com) or refer to the detailed setup guides for each integration in the sidebar. # AWS CloudWatch Source: https://docs.steadwing.com/integrations/aws Steadwing connects to AWS CloudWatch to query logs, metrics, and alarms automatically during incident analysis, helping you identify root causes faster. ## What does the AWS CloudWatch integration do? Steadwing connects to AWS CloudWatch to query your logs, metrics, and alarms during incident analysis. This gives Steadwing direct access to your AWS observability data -- application logs, infrastructure metrics, alarm states, and performance data -- so it can identify root causes faster without manual log searches. ## Why Use AWS with Steadwing? Search CloudWatch Logs for errors, patterns, and stack traces Analyze performance and health metrics from CloudWatch Track active and historical alarm states during incidents Combine AWS data with code analysis for faster RCA ## Prerequisites * An AWS account with CloudWatch data * IAM credentials with read access to CloudWatch ## How do I connect AWS CloudWatch to Steadwing? ### Step 1: Create an IAM User 1. Go to **AWS Console** → **IAM** → **Users** 2. Click **Create user** 3. Enter a username (e.g., `steadwing-readonly`) 4. Click **Next** ### Step 2: Attach Permissions Attach the following AWS managed policies to the user: | Policy Name | Purpose | | ---------------------------- | -------------------------------------------------- | | CloudWatchReadOnlyAccess | Read CloudWatch metrics and alarms | | CloudWatchLogsReadOnlyAccess | Read CloudWatch Logs and run Logs Insights queries | Alternatively, create a custom policy with these permissions: ```json theme={null} { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudwatch:DescribeAlarms", "cloudwatch:GetMetricData", "cloudwatch:GetMetricStatistics", "cloudwatch:ListMetrics", "logs:DescribeLogGroups", "logs:DescribeLogStreams", "logs:GetLogEvents", "logs:StartQuery", "logs:GetQueryResults", "logs:StopQuery" ], "Resource": "*" } ] } ``` ### Step 3: Create Access Keys 1. Open the IAM user you created 2. Go to **Security credentials** tab 3. Click **Create access key** 4. Select **Third-party service** as the use case 5. Click **Create access key** 6. Save both values: * **Access Key ID** * **Secret Access Key** Save your credentials immediately! The secret access key is shown only once. If you lose it, you'll need to create a new access key. ### Step 4: Connect AWS in Steadwing 1. Navigate to [Steadwing Settings](https://app.steadwing.com/settings) 2. Find the **AWS** integration card 3. Click to expand the collapsible form 4. Fill in the required fields: | Field | Value | | ----------------- | --------------------------------------------- | | Access Key ID | Your AWS access key (starts with `AKIA...`) | | Secret Access Key | Your AWS secret key | | Region | The AWS region to monitor (e.g., `us-east-1`) | 5. Toggle the switch to **Enable** the integration ## What data does Steadwing pull from AWS CloudWatch? When analyzing an incident, Steadwing automatically: 1. Connects to your AWS CloudWatch using the provided credentials 2. Queries **CloudWatch Logs** - application logs, error messages, stack traces 3. Queries **CloudWatch Metrics** - performance and health data 4. Checks **CloudWatch Alarms** - active and historical alarm states 5. Correlates log errors with metric anomalies to find patterns 6. Combines findings with code analysis to identify the root cause 7. Provides evidence-based diagnosis with relevant logs and metrics No manual searching required! ## What Data Can Steadwing Access? Once connected, Steadwing can read: * **CloudWatch Logs** - Application and infrastructure logs * **CloudWatch Metrics** - Performance and health metrics * **CloudWatch Alarms** - Active and historical alarm states **Security:** All access is read-only. Steadwing cannot modify your AWS resources. ## Supported AWS Services Any service that sends data to CloudWatch is supported, including: * Lambda * ECS / EKS * EC2 * RDS * API Gateway * Step Functions * And more ## Troubleshooting | Issue | Solution | | ----------------- | ---------------------------------------------------------- | | Connection failed | Verify your access key and secret are correct | | No logs found | Ensure the region matches where your logs are stored | | Permission denied | Check that the IAM user has the required policies attached | ## Security * Credentials are encrypted at rest * We recommend using a dedicated IAM user with minimal permissions * You can revoke access anytime by deleting the access key in AWS IAM ## Uninstall To disconnect the integration: 1. In Steadwing Settings, disable the AWS integration 2. In AWS IAM, delete the access key: * Navigate to **IAM** → **Users** → your Steadwing user * Go to **Security credentials** tab * Find the access key and click **Delete** This immediately revokes access. ## FAQs No. Steadwing has read-only access and can only query CloudWatch data. It cannot modify any AWS resources, configurations, or data. Use the region where your primary CloudWatch logs and metrics are stored. You can update this later if needed. Yes. Simply delete the access key in AWS IAM anytime to immediately revoke access. Currently, Steadwing connects to one region at a time. Use the region with your most critical services. Only relevant data around the incident timeframe (typically a few hours). Queries are optimized to focus on error patterns and anomalies. Create the IAM user in the account where your CloudWatch data resides. For multi-account setups, you may need to configure cross-account access. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # Better Stack Source: https://docs.steadwing.com/integrations/betterstack Steadwing pulls uptime monitor states, incident timelines, heartbeat status, and on-call schedules from Better Stack to correlate signals during root cause analysis. ## What does the Better Stack integration do? Steadwing connects to Better Stack to pull uptime monitoring, incident management, and on-call data from your Better Stack account. During root cause analysis, Steadwing gathers monitor states, incident timelines, heartbeat status, and on-call schedules to correlate signals across your entire stack and identify root causes faster. ## Why Use Better Stack with Steadwing? Pull active and recent incidents, their timelines, cause, and resolution status automatically Check which monitors are up or down, response times, and affected regions Verify whether cron jobs, background workers, and scheduled tasks are still reporting in See who was on-call when the incident happened and escalation policy details ## How do I connect Better Stack to Steadwing? ### Step 1: Create a Better Stack API Token 1. Log in to your Better Stack account 2. Navigate to **Settings** → **API tokens** 3. Click **Create API token** 4. Configure the token: * **Name:** Steadwing Integration * **Permissions:** Read-only 5. Click **Create** 6. Copy the generated API token Use a read-only token for security — Steadwing only reads data, it never creates or modifies anything in your Better Stack account. ### Step 2: Connect Better Stack in Steadwing 1. Navigate to [Steadwing Settings](https://app.steadwing.com/settings) 2. Find the **Better Stack** integration card 3. Click to expand the collapsible form 4. Paste your API token in the **API Token** field 5. Toggle the switch to **Enable** the integration ## What data does Steadwing pull from Better Stack? ### Data Collection Steadwing queries Better Stack for: * **Incidents** - Active and recent incidents, their timelines, cause, and resolution status * **Monitor States** - Which monitors are up/down, response times, and regions affected * **Heartbeat Status** - Whether expected cron jobs, background workers, or scheduled tasks are still reporting in * **On-Call Schedules** - Who was on-call when the incident happened and escalation policy details * **Status Page Data** - Current status page reports and any ongoing maintenance windows * **Webhook & Integration Info** - How alerts are being routed to other tools (Slack, PagerDuty, etc.) ## What permissions does the Better Stack integration need? ### Required Permissions The Better Stack API token requires read access to: * **Incidents** - Read incident data, timelines, and updates * **Monitors** - Read monitor status, response times, and availability * **Heartbeats** - Read heartbeat status and check-in history * **On-Call** - Read on-call calendars, schedules, and escalation policies * **Status Pages** - Read status page reports and maintenance windows * **Metadata** - Read severity levels, monitor groups, and webhook integrations Using a read-only API token is recommended. Steadwing only needs to read monitoring and incident data and never modifies your Better Stack configuration. ## FAQs Steadwing only requires a read-only API token. It never writes, updates, or deletes any data in your Better Stack account. No. Better Stack uses API token authentication — just paste your token in Steadwing Settings and the integration connects immediately. No OAuth redirect required. No. Steadwing only has read access. It queries monitor states, incidents, and on-call data but never modifies configurations or data. On-call data helps the RCA agent understand who was responsible during the incident and how escalation policies were applied, providing context for the incident timeline. The integration will stop working. Simply create a new API token in Better Stack and update it in Steadwing Settings to reconnect. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # Cloudflare Source: https://docs.steadwing.com/integrations/cloudflare Steadwing pulls DNS records, firewall rules, WAF configurations, and traffic analytics from Cloudflare to identify network-related root causes during incidents. ## What does the Cloudflare integration do? Steadwing queries DNS records, WAF rules, and network infrastructure data from your Cloudflare account to diagnose network-related incidents. During root cause analysis, Steadwing pulls zone configurations, firewall rules, and security events to identify DNS misconfigurations, blocked traffic, and network routing issues. ## Why Use Cloudflare with Steadwing? Identify DNS misconfigurations and record issues affecting traffic Detect firewall rules or WAF configurations blocking legitimate traffic Analyze traffic patterns and identify anomalies during incidents Review firewall events to understand blocked requests and threats ## How do I connect Cloudflare to Steadwing? ### Step 1: Create a Cloudflare Global API Key 1. Log in to your Cloudflare account 2. Navigate to **My Profile** → **API Tokens** * Direct link: [https://dash.cloudflare.com/profile/api-tokens](https://dash.cloudflare.com/profile/api-tokens) 3. In the **API Keys** section, locate **Global API Key** 4. Click **View** to reveal your Global API Key 5. Enter your Cloudflare password to confirm 6. Copy the API key The Global API Key provides full access to your Cloudflare account. Store it securely and never share it publicly. ### Step 2: Note Your Account Email You'll need the email address associated with your Cloudflare account. This is the email you use to log in to Cloudflare. ### Step 3: Connect Cloudflare in Steadwing 1. Navigate to [Steadwing Settings](https://app.steadwing.com/settings) 2. Find the **Cloudflare** integration card 3. Click to expand the collapsible form 4. Fill in the required fields: * **API Key:** Your Cloudflare Global API Key * **Account Email:** The email address for your Cloudflare account 5. Toggle the switch to **Enable** the integration ## What data does Steadwing pull from Cloudflare? ### Data Collection Steadwing queries Cloudflare for: * **Zones** - List of domains and zone configurations * **DNS Records** - DNS record configurations for your domains * **Firewall Rules** - Active firewall rules that may block traffic * **WAF Configuration** - Web Application Firewall packages and rules * **Rate Limits** - Rate limiting rules that may throttle requests * **Page Rules** - URL-based rules affecting traffic behavior * **Zone Settings** - SSL, caching, and security configurations * **Traffic Analytics** - Request volume and traffic patterns * **Firewall Events** - Security events and blocked requests ## What permissions does the Cloudflare integration need? ### Required Permissions The Cloudflare Global API Key provides: * **Zone Read** - Read zone configurations and settings * **DNS Read** - Read DNS record configurations * **Firewall Read** - Read firewall rules and events * **Analytics Read** - Read traffic analytics data * **Health Check Write** - Create and manage health checks * **Firewall Write** - Update firewall rules as part of automated remediation Write operations (health check creation, firewall rule updates) are only executed as part of automated remediation, only after user's approval. If you prefer more granular permissions, you can create a custom API Token with only read permissions for the resources Steadwing needs to access. ## FAQs Yes, you can create a custom API Token with read permissions for Zones, DNS, Firewall, and Analytics. However, the Global API Key setup is simpler for most users. Cloudflare's API requires both the API key and the associated account email for authentication via the X-Auth-Email header. Steadwing can create health checks and modify firewall rules as part of automated remediation, only when approved by the user. All write operations require explicit user approval before execution. Steadwing can access all zones in your Cloudflare account. During RCA, it focuses on zones relevant to the incident being analyzed. The integration will not work. Generate a new API key and update it in Steadwing Settings to reconnect. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # Datadog Source: https://docs.steadwing.com/integrations/datadog Steadwing queries Datadog for infrastructure metrics, monitor states, and application performance data to identify anomalies and bottlenecks during incident analysis. ## What does the Datadog integration do? Steadwing connects to Datadog to query infrastructure metrics, monitor states, and application performance data from your Datadog account. During root cause analysis, Steadwing pulls relevant metrics to identify anomalies, resource bottlenecks, and performance degradation patterns that correlate with production incidents. ## Why Use Datadog with Steadwing? Analyze infrastructure and application metrics during incidents Identify unusual metric patterns that indicate root causes Track CPU, memory, disk, and network usage during incidents Connect Datadog alerts to incident timing for better context ## How do I connect Datadog to Steadwing? ### Step 1: Create Datadog API Keys #### Generate API Key 1. Log in to your Datadog account 2. Navigate to **Organization Settings** → **API Keys** * Direct link: [https://app.datadoghq.com/organization-settings/api-keys](https://app.datadoghq.com/organization-settings/api-keys) 3. Click **+ New Key** 4. Configure the key: * **Name:** Steadwing Integration 5. Click **Create Key** 6. Copy the generated API key #### Generate Application Key 1. In Datadog, go to **Organization Settings** → **Application Keys** * Direct link: [https://app.datadoghq.com/organization-settings/application-keys](https://app.datadoghq.com/organization-settings/application-keys) 2. Click **+ New Key** 3. Configure the key: * **Name:** Steadwing Integration 4. Click **Create Key** 5. Copy the Application Key ID (not the full key) Save your keys immediately! Store them securely as they provide access to your Datadog data. ### Step 2: Identify Your Datadog Region Determine your Datadog region by checking your Datadog URL: * `app.datadoghq.com` → **us1** * `us3.datadoghq.com` → **us3** * `us5.datadoghq.com` → **us5** * `app.datadoghq.eu` → **eu** * `ap1.datadoghq.com` → **ap1** ### Step 3: Connect Datadog in Steadwing 1. Navigate to [Steadwing Settings](https://app.steadwing.com/settings) 2. Find the **Datadog** integration card 3. Click to expand the collapsible form 4. Fill in the required fields: * **API Key:** Your Datadog API key * **Region:** Your Datadog site (us1, us3, us5, eu, or ap1) * **Application Key:** Your Datadog Application Key ID 5. Toggle the switch to **Enable** the integration ## What data does Steadwing pull from Datadog? ### Data Collection Steadwing queries Datadog for: * **Infrastructure Metrics** - CPU, memory, disk, network usage * **Application Metrics** - Request rates, latency, error rates * **Custom Metrics** - Any custom metrics you've configured * **Monitor States** - Active alerts and monitor status * **Event Timeline** - Deployments, configuration changes, alerts ## What permissions does the Datadog integration need? ### Required Permissions The Datadog API integration requires: * **metrics\_read** - Read time series metric data * **monitors\_read** - Read monitor configurations and states ## FAQs The API Key authenticates your organization, while the Application Key identifies the specific user or service making API calls. Both are required for full Datadog API access. Check your Datadog URL. For example, if you access Datadog at `us3.datadoghq.com`, your region is `us3`. If you use `app.datadoghq.com`, your region is `us1`. No, Steadwing only has read access. It queries metrics and monitor states but never modifies configurations, dashboards, or data. Yes, API calls count toward your Datadog rate limits. Steadwing is optimized to make minimal API calls, typically only during active RCA. The integration will not work. Simply create new API keys and update them in Steadwing Settings to reconnect. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # E2B Source: https://docs.steadwing.com/integrations/e2b Steadwing connects to E2B to pull sandbox logs, lifecycle events, and resource metrics, helping you diagnose failures in AI applications that use sandboxed code execution. ## What does the E2B integration do? Steadwing accesses sandbox execution data from your E2B account to diagnose AI application failures. During root cause analysis, Steadwing pulls sandbox logs, lifecycle events, resource metrics, and template configurations to identify why sandboxed code execution failed or degraded. ## Why Use E2B with Steadwing? List running and paused sandboxes to understand what was active during an incident Pull sandbox logs to find execution errors, crashes, and unexpected output Detect CPU, memory, and disk exhaustion that caused sandbox failures Identify unexpected sandbox terminations, timeouts, and state changes ## How do I connect E2B to Steadwing? ### Step 1: Get Your E2B API Key 1. Sign up or log in at [e2b.dev](https://e2b.dev) 2. Navigate to the **Dashboard** 3. Go to **Settings** → **API Keys** 4. Copy your existing API key or create a new one Store your API key securely. It provides access to your E2B account data including sandbox logs and metrics. ### Step 2: Connect E2B in Steadwing 1. Navigate to [Steadwing Settings](https://app.steadwing.com/settings) 2. Find the **E2B** integration card 3. Click to expand the collapsible form 4. Paste your API key in the **API Key** field 5. Toggle the switch to **Enable** the integration ## What data does Steadwing pull from E2B? ### Data Collection Steadwing queries E2B for: * **Sandbox List** - Running, paused, and recently terminated sandboxes and their states * **Sandbox Logs** - Execution output, error messages, and crash reports from sandbox processes * **Lifecycle Events** - Sandbox creation, termination, pause/resume events, and timeout triggers * **Resource Metrics** - CPU, memory, and disk usage to detect resource exhaustion * **Template Status** - Build status and configuration of sandbox templates * **Team Metrics** - Concurrent sandbox counts and limit usage across your team ## What permissions does the E2B integration need? ### Required Permissions The E2B API key requires read access to: * **Sandboxes** - Read sandbox list, status, and timeout configuration * **Logs** - Read execution output and error messages * **Lifecycle** - Read start, stop, pause, resume, and timeout events * **Resources** - Read CPU, memory, and disk usage metrics * **Templates** - Read template list, build status, and installed packages * **Team** - Read concurrent sandbox counts and usage limits Steadwing only needs read access to your E2B account. It never creates, modifies, or terminates sandboxes. ## FAQs Steadwing reads sandbox states, execution logs, lifecycle events, resource metrics, and template configurations. It does NOT create, modify, or terminate any sandboxes. No. E2B uses API key authentication — just paste your key in Steadwing Settings and the integration connects immediately. No OAuth redirect required. No. Steadwing only has read access. It queries sandbox states, logs, and metrics but never executes code or modifies sandbox configurations. Steadwing can still access logs and lifecycle events for recently terminated sandboxes, subject to E2B's data retention policy. The integration will stop working. Simply create a new API key in your E2B dashboard and update it in Steadwing Settings to reconnect. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # Elasticsearch Source: https://docs.steadwing.com/integrations/elasticsearch Steadwing connects to your Elasticsearch cluster to query logs, metrics, and traces using natural language and ES|QL, so you get root cause analysis without manual log searching. ## What does the Elasticsearch integration do? The Elasticsearch integration lets Steadwing query your logs, metrics, and traces using natural language and ES|QL during incident analysis, so you get automated root cause analysis instead of manual log searching. Steadwing leverages Kibana's Agent Builder tools to intelligently search your data, identify patterns, and correlate findings with code changes. ## Why Use Elasticsearch with Steadwing? Query logs using natural language - no complex syntax needed Run powerful analytical queries to aggregate and analyze data Leverage your pre-configured Agent Builder tools Automatically link log patterns to code changes and deployments ## How do I connect Elasticsearch to Steadwing? ### Step 1: Get Your Kibana URL Your Kibana URL format depends on your deployment type: **Elastic Cloud:** ```text theme={null} https://your-deployment-id.kb.region.cloud.es.io ``` **Elastic Serverless:** ```text theme={null} https://your-project.es.region.cloud.es.io ``` **Example:** ```text theme={null} https://abc123def.kb.us-east-1.aws.found.io ``` ### Step 2: Create an API Key 1. Navigate to **Kibana → Stack Management → API Keys** 2. Click **Create API Key** 3. Configure the following privileges: ```json theme={null} { "name": "steadwing-rca-integration", "role_descriptors": { "steadwing_role": { "cluster": ["monitor"], "indices": [ { "names": ["logs-*", "metrics-*"], "privileges": ["read", "view_index_metadata"] } ], "applications": [ { "application": "kibana-.kibana", "privileges": ["read_onechat", "space_read"], "resources": ["*"] } ] } } } ``` **Required Privileges:** * `read_onechat` - Access to Agent Builder MCP * `space_read` - Access to Kibana spaces * `read` + `view_index_metadata` - Query your indices 4. Click **Create API Key** 5. **Copy the API key** - you'll need it in Step 3 Save your API key immediately! It's shown only once. If you lose it, you'll need to create a new key. ### Step 3: Connect Elasticsearch in Steadwing 1. Navigate to [Steadwing Settings](https://app.steadwing.com/settings) 2. Find the **Elasticsearch** integration card 3. Click to expand the collapsible form 4. Fill in the required fields: * **Kibana URL:** Your full Kibana instance URL (e.g., `https://abc123def.kb.us-east-1.aws.found.io`) * **API Key:** The API key you created 5. Toggle the switch to **Enable** the integration ## What happens when Steadwing queries Elasticsearch? When analyzing an incident, Steadwing automatically: 1. **Discovers Tools** - Identifies available tools in your Kibana Agent Builder 2. **Extracts Context** - Parses error messages for service names, timestamps, and error types 3. **Queries Strategically:** * Semantic search for broad pattern matching * ES|QL for detailed aggregations and analysis * Custom tools if configured 4. **Correlates Findings** - Combines Elasticsearch data with code changes, metrics, and deployments 5. **Generates Timeline** - Builds chronological view of events leading to the incident No manual log searching required! ## Requirements * **Elastic Cloud 9.2+** or **Elastic Serverless** deployment * Kibana instance with Agent Builder enabled * API Key with appropriate privileges ## Use Cases **Error Investigation:** ```text theme={null} Example: "Show me all errors in the payment service from the last hour" Steadwing uses semantic search to find relevant error logs automatically ``` **Performance Analysis:** ```text theme={null} Example: "Find timeout errors related to the database" ES|QL aggregates timeouts by service and identifies patterns ``` **Deployment Correlation:** ```text theme={null} Steadwing correlates error spikes with recent deployments Timeline shows: Deploy → Error spike → Root cause identified ``` ## What Data Can Steadwing Access? **Read-Only Access:** * Only indices specified in your API key (e.g., `logs-*`, `metrics-*`) * Time-bounded queries (typically 1-6 hours around incident) * Limited results (50-100 per query) **Security:** * Cannot write, update, or delete data * Cannot modify Kibana dashboards or settings * API keys encrypted at rest * Queries executed in real-time - no data storage ## Uninstall To disconnect the integration: 1. In Steadwing Settings, disable the Elasticsearch integration 2. In Kibana, delete the API key: * Navigate to **Stack Management → API Keys** * Find "steadwing-rca-integration" (or your chosen name) * Click **Delete** This immediately revokes access. ## FAQs No. The API key only has read permissions. Steadwing cannot write, update, or delete any data in your Elasticsearch cluster. Elastic Cloud 9.2+ and Elastic Serverless. Older versions are not supported due to Agent Builder requirements. No. Steadwing can use semantic search and ES|QL without custom tools. However, custom tools can improve results for organization-specific queries. Verify your API key includes `read_onechat` and `space_read` privileges. These are required for Agent Builder access. Only data within the incident timeframe (typically 1-6 hours). Queries are limited to 50-100 results to prevent overwhelming data transfer. Agent Builder must be enabled in your Kibana instance. Contact Elastic support to enable it for your deployment. Yes. In the API key privileges, specify only the indices you want Steadwing to access (e.g., `logs-production-*` instead of `logs-*`). Currently, only Elastic Cloud 9.2+ and Elastic Serverless are supported. On-premises deployments require these versions with Agent Builder enabled. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # GCP Source: https://docs.steadwing.com/integrations/gcp Steadwing connects to Google Cloud Platform to query Cloud Logging, Cloud Trace, and Error Reporting, giving you AI-powered root cause analysis across your GCP infrastructure. ## What does the GCP integration do? Steadwing reads logs, traces, and errors from your GCP projects to perform AI-powered root cause analysis. During incidents, Steadwing queries Cloud Logging, Cloud Trace, and Error Reporting to identify issues, trace request flows, and analyze error patterns that correlate with production problems. ## Why Use GCP with Steadwing? Access Cloud Logging data to investigate application and infrastructure logs Analyze request traces to identify latency and performance bottlenecks Query Error Reporting for exception patterns and error frequencies Correlate incidents with GCP service events and resource states ## Benefits * **Comprehensive Log Access** - Query logs from all GCP services and custom applications * **Trace-Based Debugging** - Follow request flows across microservices to find root causes * **Error Pattern Detection** - Identify recurring errors and their distribution * **Read-Only Access** - Steadwing only reads data, with no write permissions required * **Multi-Project Support** - Connect multiple GCP projects for unified analysis ## How do I connect GCP to Steadwing? ### Step 1: Create a Service Account 1. Go to the [GCP Console](https://console.cloud.google.com) 2. Select your project 3. Navigate to **IAM & Admin** → **Service Accounts** * Direct link: [https://console.cloud.google.com/iam-admin/serviceaccounts](https://console.cloud.google.com/iam-admin/serviceaccounts) 4. Click **+ Create Service Account** 5. Configure the service account: * **Service account name:** steadwing-integration * **Service account ID:** steadwing-integration (auto-generated) * **Description:** Steadwing read-only access for logs, traces, and errors 6. Grant the following read-only roles: * **Logs Viewer** (`roles/logging.viewer`) * **Cloud Trace Viewer** (`roles/cloudtrace.user`) * **Error Reporting Viewer** (`roles/errorreporting.viewer`) 7. Click **Done** to create the service account Steadwing only requires read permissions. Do not grant write or admin roles to maintain security. ### Step 2: Connect via Google Authentication 1. Navigate to [Steadwing Integrations](https://app.steadwing.com/integrations) 2. Find the **Google Cloud Platform** integration card 3. Toggle the switch to **Enable** the integration 4. You'll be redirected to Google's authentication page 5. Sign in with your Google account that has access to your GCP project 6. Grant Steadwing the requested read-only permissions 7. You'll be redirected back to Steadwing with the integration connected ## What data does Steadwing pull from GCP? ### Data Collection Steadwing queries GCP for: * **Cloud Logging** - Application logs, system logs, audit logs, and custom logs * **Cloud Trace** - Distributed traces showing request latency and service dependencies * **Error Reporting** - Error events, stack traces, and error frequency data * **Resource Metadata** - GCP service information and resource configurations ### Read-Only Operations All GCP API calls are read-only: * ✅ Read log entries * ✅ Query trace data * ✅ View error reports * ❌ No write operations * ❌ No resource modifications * ❌ No configuration changes ## What permissions does the GCP integration need? ### Required Permissions The GCP service account requires these read-only roles: | Role | Permission | Purpose | | -------------------------- | ----------------------------- | --------------------------------- | | **Logs Viewer** | `roles/logging.viewer` | Read Cloud Logging entries | | **Cloud Trace Viewer** | `roles/cloudtrace.user` | Access distributed trace data | | **Error Reporting Viewer** | `roles/errorreporting.viewer` | Read error reports and statistics | ### Multi-Project Setup To monitor multiple GCP projects: 1. Ensure your Google account has access to multiple projects 2. Authenticate once through the Steadwing integrations page 3. Select which projects you want to grant Steadwing access to during the OAuth flow ## FAQs No, Steadwing only requires read-only access. The integration uses Logs Viewer, Cloud Trace Viewer, and Error Reporting Viewer roles, which provide no write capabilities. Yes, you need to create a service account in your GCP project with the appropriate read-only roles. After that, authentication is handled automatically through Google's OAuth flow when you toggle the integration in Steadwing. No, the required permissions are strictly read-only. Steadwing cannot modify logs, delete traces, change configurations, or alter any GCP resources. Use a Google account that has access to your GCP projects. The account should have permissions to view the resources that the service account has been granted access to. Yes, API calls made by Steadwing count toward your GCP project quotas. The integration is optimized to make minimal calls, typically only during active incident analysis. Yes, during the OAuth authentication flow, you can select multiple projects to grant Steadwing access to. Your Google account must have appropriate permissions for each project. To revoke access, go to your [Google Account permissions page](https://myaccount.google.com/permissions), find Steadwing, and remove access. You can also toggle off the integration in Steadwing Settings. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # GitHub Source: https://docs.steadwing.com/integrations/github Connect GitHub to Steadwing so every deployment, commit, and release is automatically correlated with production incidents during root cause analysis. ## What does the GitHub integration do? The GitHub integration automatically correlates production incidents with recent code changes -- deployments, commits, pull requests, and releases -- so Steadwing can pinpoint which change likely caused the problem. Steadwing reads your repository data during root cause analysis to identify the responsible commit or deployment and propose code-level fixes. ## Why Use GitHub with Steadwing? Correlate incidents with recent deployments and releases Identify which commits may have caused production issues Enable Steadwing to analyze your code for better solution proposals Link incidents to specific PRs, commits, and deployment times ## Benefits * **Faster Root Cause Identification** - Quickly pinpoint which code change triggered an incident * **Automated Code Analysis** - Steadwing reviews relevant code sections during RCA * **Deployment Context** - Understand what was deployed when an incident occurred * **Better Solution Proposals** - Get context-aware fixes based on your actual codebase * **Historical Insights** - Track patterns between code changes and incidents over time ## How do I connect GitHub to Steadwing? ### Step 1: Connect GitHub OAuth 1. Navigate to [Steadwing Settings](https://app.steadwing.com/settings) 2. Find the **GitHub** integration card 3. Click the **Connect** button 4. You will be redirected to GitHub's authorization page 5. Click **Authorize Steadwing** to complete OAuth ### Step 2: Install Steadwing GitHub App After completing OAuth, you must install the Steadwing GitHub App on your repositories: 1. Follow the installation link provided in the settings page (Step 2) 2. Choose where to install the app: * **All repositories** - Install on all current and future repos * **Select repositories** - Choose specific repositories 3. Click **Install** to complete the setup 4. The Steadwing app will now have access to track changes in your selected repositories ## What data does Steadwing pull from GitHub? ### Automatic Event Tracking Steadwing automatically monitors and tracks: * **Commits** - Every commit pushed to your repositories * **Pull Requests** - PR merges and their associated changes * **Releases** - Tagged releases and their deployment times * **Deployments** - Deployment events via GitHub Actions or other CI/CD tools ### Code Analysis Steadwing can: * Review relevant files and functions * Identify potentially problematic changes * Suggest code-level fixes * Link incidents to specific lines of code ## What permissions does the GitHub integration need? ### Required Permissions The GitHub integration requires: * **repo** - Full access to private and public repositories * Read repository contents * Read commit history * Read pull request data * Write access for branch creation and pull request creation * **read:org** - Organization membership information * Read organization and team membership Steadwing never pushes directly to default or protected branches. All code changes are proposed via pull requests on new branches, only after user's approval. ### Repository Access You can control which repositories Steadwing can access: 1. Go to GitHub Settings → Integrations → Applications 2. Find **Steadwing** in the list 3. Click **Configure** 4. Modify repository access settings 5. Save changes ## FAQs OAuth (Step 1) authorizes Steadwing to access GitHub, but installing the GitHub App (Step 2) grants repository-level access and enables webhook events for real-time tracking. Yes, during Step 2 you can select specific repositories instead of granting access to all repositories. You can modify this later in GitHub settings. Steadwing can create branches and open pull requests for proposed code fixes, but only when triggered by user action. Steadwing never pushes directly to default or protected branches — all changes are proposed via PRs for your review. If you selected "All repositories" during installation, new repositories will automatically be tracked. Otherwise, you need to manually grant access to new repositories in GitHub settings. Yes, Steadwing works with both public and private repositories. The `repo` permission grants access to private repositories. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # GitLab Source: https://docs.steadwing.com/integrations/gitlab Connect GitLab to Steadwing so deployments, merge requests, commits, and CI/CD pipeline events are automatically correlated with production incidents during root cause analysis. ## What does the GitLab integration do? The GitLab integration automatically correlates production incidents with recent code changes -- deployments, commits, merge requests, and CI/CD pipeline events -- so Steadwing can pinpoint which change likely caused the problem. Steadwing reads your GitLab repository data during root cause analysis to identify the responsible commit, merge request, or failed pipeline and propose code-level fixes. ## Why Use GitLab with Steadwing? Correlate incidents with recent deployments and releases Identify which commits and merge requests may have caused production issues Monitor pipeline failures and correlate them with incidents Link incidents to specific MRs, commits, and deployment times ## Benefits * **Faster Root Cause Identification** - Quickly pinpoint which code change triggered an incident * **Automated Code Analysis** - Steadwing reviews relevant code sections during RCA * **Deployment Context** - Understand what was deployed when an incident occurred * **Pipeline Failure Detection** - Identify CI/CD pipeline issues that may have contributed to incidents * **Better Solution Proposals** - Get context-aware fixes based on your actual codebase * **Historical Insights** - Track patterns between code changes and incidents over time ## How do I connect GitLab to Steadwing? ### Step 1: Connect GitLab OAuth 1. Navigate to [Steadwing Settings](https://app.steadwing.com/settings) 2. Find the **GitLab** integration card 3. Click the **Connect** button 4. You will be redirected to GitLab's authorization page 5. Click **Authorize** to complete OAuth ### Step 2: Grant Repository Access After completing OAuth, configure which repositories Steadwing can access: 1. In GitLab, go to **Settings** → **Applications** → **Authorized Applications** 2. Find **Steadwing** in the list 3. Configure repository access permissions 4. Steadwing will now have access to track changes in your selected repositories ## What data does Steadwing pull from GitLab? ### Automatic Event Tracking Steadwing automatically monitors and tracks: * **Commits** - Every commit pushed to your repositories * **Merge Requests** - MR merges and their associated changes * **Releases** - Tagged releases and their deployment times * **CI/CD Pipelines** - Pipeline runs, failures, and job statuses * **Deployments** - Deployment events via GitLab CI/CD ### Code Analysis Steadwing can: * Review relevant files and functions * Identify potentially problematic changes * Suggest code-level fixes * Link incidents to specific lines of code * Analyze merge request diffs ## What permissions does the GitLab integration need? ### Required Permissions The GitLab integration requires: * **read\_api** - Read access to API endpoints * Read repository contents * Read commit history * Read merge request data * Read pipeline information * **read\_repository** - Repository access * Clone and read repository contents * Access file contents and history ### Repository Access You can control which repositories Steadwing can access: 1. Go to GitLab Settings → Applications → Authorized Applications 2. Find **Steadwing** in the list 3. Click **Edit** to modify permissions 4. Adjust repository access settings 5. Save changes ## Supported Features ### Code Investigation * Fetch file contents from repositories * Analyze commit history and diffs * Review merge request changes * Track code changes over time ### CI/CD Pipeline Monitoring * Monitor pipeline runs and failures * Identify failed jobs and stages * Correlate pipeline failures with incidents * Track deployment events ### Merge Request Analysis * Review recent merge requests * Analyze MR diffs and changes * Identify potentially problematic merges * Track MR approval and merge times ## FAQs Currently, Steadwing supports GitLab.com (SaaS). Support for self-hosted GitLab instances is planned for a future release. Yes, you can configure repository access permissions in GitLab's application settings. Steadwing will only access repositories you explicitly grant permission to. No, Steadwing only has read access. Steadwing analyzes your code but never modifies, commits, or pushes changes to your repositories. You can grant access to new repositories at any time by updating the application permissions in GitLab settings. Steadwing will automatically start tracking changes in newly authorized repositories. Yes, Steadwing works with both public and private repositories. The integration respects GitLab's permission model and only accesses repositories you explicitly authorize. Steadwing supports GitLab's nested group structure. When analyzing repositories, it correctly handles project paths in the format `group/subgroup/project` and uses URL-encoded project IDs for API calls. Yes, Steadwing monitors CI/CD pipeline runs and can correlate pipeline failures with incidents. Pipeline monitoring helps identify whether a deployment or build issue contributed to production problems. Go to [Settings](https://app.steadwing.com/settings), find the GitLab integration, and click **Disconnect**. You should also revoke access in GitLab Settings → Applications → Authorized Applications. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # Grafana Source: https://docs.steadwing.com/integrations/grafana Steadwing queries Prometheus metrics and Loki logs through Grafana to identify error patterns, latency spikes, and resource bottlenecks during incident analysis. ## What does the Grafana integration do? Steadwing connects to Grafana to query Prometheus metrics and Loki logs during incident analysis. The Grafana integration helps Steadwing identify root causes faster by analyzing your observability data -- from error rates and latency spikes to application logs and stack traces. ## Why Use Grafana with Steadwing? Analyze CPU, memory, error rates, and latency from Prometheus Search Loki for error messages, stack traces, and patterns Automatically link metric spikes to error logs Combine observability data with code analysis for faster RCA ## How do I connect Grafana to Steadwing? ### Step 1: Get Your Grafana URL Your Grafana web address. Examples: * **Grafana Cloud:** `https://yourcompany.grafana.net` * **Self-hosted:** `https://grafana.yourcompany.com` * **AWS EC2:** `https://ec2-xx-xx-xx-xx.compute.amazonaws.com:3000` * **On-premises:** `https://10.0.1.50:3000` Works with any Grafana deployment - Cloud, self-hosted, or on-premises. ### Step 2: Create a Service Account Token 1. Open Grafana and navigate to **Administration** → **Service Accounts** * Direct link: `https://your-grafana-url/org/serviceaccounts` 2. Click **Add service account** 3. Configure the account: * **Display name:** Steadwing Integration (or your preferred name) * **Role:** Viewer (read-only access) 4. Click **Create** 5. Click **Add service account token** 6. Configure the token: * **Display name:** Steadwing Token * **Expiration:** Choose your preferred duration (or no expiration) 7. Click **Generate token** 8. Copy the token (starts with `glsa_...`) Save your token immediately! It's shown only once. If you lose it, you'll need to create a new token. ### Step 3: Connect Grafana in Steadwing 1. Navigate to [Steadwing Settings](https://app.steadwing.com/settings) 2. Find the **Grafana** integration card 3. Click to expand the collapsible form 4. Fill in the required fields: * **Grafana URL:** Your Grafana web address (e.g., `https://yourcompany.grafana.net`) * **Service Account Token:** Your token (starts with `glsa_`) 5. Toggle the switch to **Enable** the integration ## What data does Steadwing pull from Grafana? When analyzing an incident, Steadwing automatically: 1. Checks your Grafana for Prometheus and Loki datasources 2. Queries **Prometheus metrics** (if available) - error rates, CPU/memory usage, latency 3. Queries **Loki logs** (if available) - error messages, stack traces, application logs 4. Correlates metric spikes with log errors to find patterns 5. Combines findings with code analysis to identify the root cause 6. Provides evidence-based diagnosis with relevant metrics and logs No manual searching required! ## Requirements * **Grafana version:** 9.0 or newer * **Service account role:** Viewer (read-only) * **Datasources:** At least one of: * Prometheus (for metrics) * Loki (for logs) * Both (recommended for best results) ## Datasource Flexibility The integration automatically adapts to what you have: | Your Setup | What Happens | | ---------------------- | -------------------------------------------- | | Prometheus only | Analyzes metrics (CPU, errors, latency) | | Loki only | Analyzes logs (error messages, stack traces) | | Both Prometheus + Loki | Best results! Correlates metrics with logs | You don't need both datasources - Steadwing uses whatever you have configured. ## What Data Can Steadwing Access? **Prometheus Metrics:** * Performance data (CPU, memory, latency) * Error rates and request counts * Custom application metrics * Only data around incident timeframes **Loki Logs:** * Application logs and error messages * Stack traces and exceptions * Service logs for affected applications * Only relevant time ranges **Security:** Read-only access. Cannot modify dashboards, alerts, or data. ## Uninstall To disconnect the integration: 1. In Steadwing Settings, disable the Grafana integration 2. In Grafana, delete the service account: * Navigate to **Administration** → **Service Accounts** * Find "Steadwing Integration" (or your chosen name) * Click **Delete service account** This immediately revokes access. ## FAQs No. Steadwing has read-only access and can only query data. It cannot modify any Grafana configuration, dashboards, alerts, or data. No. The integration works with either one or both. Having both provides the best results since it can correlate metrics with logs. Yes. Simply delete the service account token in Grafana anytime to immediately revoke access. Perfect! Steadwing will analyze metrics like error rates, latency, CPU, and memory usage. Great! Steadwing will analyze logs including error messages, stack traces, and patterns. Yes! Works with Grafana Cloud, self-hosted, or on-premises installations. Only relevant data around the incident timeframe (typically a few hours). Queries are optimized to focus on error patterns and anomalies. Add at least one Prometheus or Loki datasource in Grafana, then reconnect the integration. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # Kubernetes Source: https://docs.steadwing.com/integrations/kubernetes Steadwing connects to your Kubernetes clusters to monitor pod health, resource utilization, deployment states, and cluster events for AI-powered incident analysis. ## What does the Kubernetes integration do? Steadwing connects to your Kubernetes clusters to access pod status, container logs, and cluster events during incident analysis. Steadwing analyzes pod health, resource utilization, and deployment states to identify infrastructure-related issues that correlate with production incidents. ## Why Use Kubernetes with Steadwing? Track pod status, restarts, and failures during incidents Access and analyze pod logs to identify error patterns Monitor cluster resource usage and capacity issues Connect Kubernetes events to incident timing for better context ## How do I connect Kubernetes to Steadwing? Choose your platform and copy-paste the complete command block: ```bash theme={null} # 1. Connect to your EKS cluster (replace with your values) aws eks update-kubeconfig --name YOUR_CLUSTER_NAME --region YOUR_REGION # 2. Create read-only service account and permissions kubectl apply -f - < steadwing-kubeconfig.yaml < ```bash theme={null} # 1. Connect to your GKE cluster (replace with your values) gcloud container clusters get-credentials YOUR_CLUSTER_NAME --region YOUR_REGION --project YOUR_PROJECT_ID # 2. Create read-only service account and permissions kubectl apply -f - < steadwing-kubeconfig.yaml < ```bash theme={null} # 1. Connect to your AKS cluster (replace with your values) az aks get-credentials --resource-group YOUR_RESOURCE_GROUP --name YOUR_CLUSTER_NAME # 2. Create read-only service account and permissions kubectl apply -f - < steadwing-kubeconfig.yaml < ```bash theme={null} # 1. Make sure you're connected to your cluster kubectl cluster-info # 2. Create read-only service account and permissions kubectl apply -f - < steadwing-kubeconfig.yaml < ### Upload to Steadwing After running the commands above: 1. **Option A:** Copy the entire YAML output from your terminal 2. **Option B:** Use the generated file `steadwing-kubeconfig.yaml` 3. Go to **Integrations** → **Kubernetes** → **Connect** 4. Upload or paste the kubeconfig content 5. Done! ## What This Creates * Service account with read access and scoped write access for automated remediation * Token valid for 10 years * Read access to: pods, logs, events, deployments, jobs * Write access to: workload scaling, pod management, configuration updates * Isolated in `steadwing` namespace * Works with all Kubernetes versions 1.22+ ## What data does Steadwing pull from Kubernetes? ### Data Collection Steadwing queries Kubernetes for: * **Pod Status** - Running, pending, failed, and crashed pods * **Pod Logs** - Container logs for error analysis * **Events** - Cluster events related to scheduling, scaling, and failures * **Deployments** - Deployment status and replica counts * **Resource Usage** - Node and pod resource allocation ## What permissions does the Kubernetes integration need? ### Required Permissions The service account has **read access** to: * `pods`, `pods/log` - View pods and their logs * `events` - Read cluster events * `nodes`, `namespaces`, `services`, `endpoints` - View cluster resources * `deployments`, `replicasets`, `statefulsets`, `daemonsets` - View workload status * `jobs`, `cronjobs` - View batch workloads The service account has **scoped write access** for automated remediation: * `deployments`, `statefulsets`, `daemonsets`, `replicasets` - `patch`, `update` for workload updates * `deployments/scale`, `statefulsets/scale`, `replicasets/scale` - `patch`, `update` for scaling operations * `pods` - `create`, `delete` for pod management * `pods/exec` - `create` for executing commands in pods * `configmaps`, `secrets`, `services` - `create`, `update`, `patch` for configuration changes ### Security * Read access for monitoring, scoped write access for automated remediation * All write operations require explicit user approval before execution * Token-based authentication * Token expiration set to 1 year (renewable) ## Uninstall To remove the Steadwing integration from your cluster: ```bash theme={null} kubectl delete namespace steadwing kubectl delete clusterrole steadwing-readonly kubectl delete clusterrolebinding steadwing-readonly-binding ``` ## FAQs The integration works with Kubernetes 1.22 and later. It's compatible with all major distributions including EKS, GKE, AKS, and self-hosted clusters. Yes, Steadwing can execute approved infrastructure changes as part of automated remediation. Supported actions include scaling deployments, restarting pods, executing commands in pods, and updating configurations. All actions require explicit user approval before execution. The token is generated with a 10-year (87600 hours) validity period. You'll need to regenerate it after expiration by running the setup script again. The integration will stop working. You'll need to run the setup script again to recreate the service account and generate a new kubeconfig file. Yes! Run the setup script for each cluster. Each cluster will generate its own kubeconfig file that you can upload separately to Steadwing. Yes, as long as Steadwing can reach the cluster's API server endpoint. For private clusters, you may need to configure network access or use a VPN. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # Linear Source: https://docs.steadwing.com/integrations/linear Connect Linear to Steadwing so you can trigger AI-powered root cause analysis by assigning issues to the Steadwing bot or @mentioning Steadwing in any issue comment. ## What does the Linear integration do? The Linear integration lets you trigger AI-powered root cause analysis directly from your Linear workspace -- just assign an issue to the Steadwing bot or @mention Steadwing in a comment. Steadwing automatically performs RCA, posts detailed findings and suggested fixes as threaded comments, and updates issue status so your team can resolve incidents without leaving Linear. ## Why Use Linear with Steadwing? Trigger root cause analysis by simply assigning issues to Steadwing Mention @Steadwing in any issue comment to get instant analysis Receive detailed RCA results directly in Linear issue comments Once installed by an admin, any workspace member can use Steadwing ## Benefits * **Native Workflow Integration** - No need to switch between tools; manage incidents directly in Linear * **Automatic Analysis** - Get instant RCA when issues are assigned or bot is mentioned * **Collaborative Investigation** - Share insights and solutions with your team in Linear threads * **Workspace-Wide Availability** - All team members can leverage Steadwing after initial setup * **Real-Time Updates** - Track analysis progress with status updates in Linear ## How do I connect Linear to Steadwing? ### Connect Linear 1. Navigate to [Steadwing Integrations](https://app.steadwing.com) 2. Find the **Linear** integration card 3. Click the **Connect** toggle 4. You will be redirected to Linear's authorization page 5. Click **Authorize** to complete the connection 6. The Steadwing bot will automatically be installed in your Linear workspace **Admin Setup, Team-Wide Use**: Once an admin installs the Linear integration, any member of your Linear workspace can assign issues to Steadwing or @mention the bot in comments. No additional setup required for team members! ## How do I trigger RCA from Linear? ### Conversational Follow-up After the RCA is completed, you can continue the conversation with Steadwing by tagging the bot in follow-up comments: * Ask clarifying questions about the root cause * Request additional details about suggested solutions * Inquire about alternative approaches or fixes * Get explanations about specific technical aspects Simply @mention Steadwing in a new comment and ask your question. The bot will respond with context-aware answers based on the completed RCA. **Example:** ```text theme={null} Issue: API endpoint returning 500 errors ✅ Steadwing: RCA complete! Root cause: Database connection pool exhausted... └─ Developer: @Steadwing What would be the impact of increasing the pool size to 100? └─ Steadwing: Increasing the pool size to 100 would help handle more concurrent requests... ``` ### Delegation Flow: Assigning Issues When you assign a Linear issue to Steadwing, here's what happens: 1. **Assignment** - You assign a Linear issue to the Steadwing bot 2. **Duplicate Check** - System checks if this issue is already being processed 3. **Issue Creation** - Creates a `LinearIssue` record with `PROCESSING` status 4. **Status Indicator** - Adds 👀 emoji reaction to indicate analysis is in progress 5. **RCA Execution** - Runs comprehensive root cause analysis 6. **Results Posted** - Posts detailed findings and solutions in Linear 7. **Status Update** - Updates issue status to `COMPLETED` or `FAILED` with ✅ or ❌ emoji **Example:** ```text theme={null} Issue: API endpoint returning 500 errors Assigned to: Steadwing 👀 (RCA in progress...) ✅ └─ Steadwing: RCA complete! Root cause: Database connection pool exhausted due to missing timeout configuration Suggested fix: Add connection timeout in database config (pool.timeout = 30) [View full details](link) ``` ### @Mention Flow: Comment-Based Analysis When you @mention Steadwing in an issue comment: 1. **Mention Detection** - User @mentions the Steadwing bot in a comment 2. **Bot Filter** - Verifies the comment is not from the bot itself 3. **Duplicate Check** - Ensures this mention hasn't been processed already 4. **Placeholder Creation** - Creates a placeholder `LinearIssue` record 5. **Status Indicator** - Adds 👀 emoji reaction to indicate analysis is in progress 6. **RCA Execution** - Runs root cause analysis 7. **Threaded Results** - Posts detailed findings as a threaded reply 8. **Status Update** - Updates the LinearIssue status to `COMPLETED` or `FAILED` with ✅ or ❌ emoji **Example:** ```text theme={null} Issue: Memory leak in production worker └─ Developer: @Steadwing can you investigate this memory leak? 👀 (RCA in progress...) ✅ └─ Steadwing: Analysis complete! Root cause: EventEmitter listeners not being removed in worker cleanup Suggested fix: Add removeAllListeners() in worker shutdown handler [View full details](link) ``` ## What permissions does the Linear integration need? ### Required Permissions The Linear integration requires the following permissions: * `read` - Read issues, projects, and workspace information * `write` - Post comments and update issue status * `comment:create` - Create comments on issues * `issue:read` - Read issue details and metadata ### Workspace Access Once installed by an admin: * All workspace members can assign issues to Steadwing * All workspace members can @mention Steadwing in comments * No additional permissions or setup required per user * Works across all projects in the workspace ### Issue States Steadwing tracks the following states: * `PROCESSING` - Analysis is in progress * `COMPLETED` - Analysis finished successfully * `FAILED` - Analysis encountered an error ## FAQs No! Once an admin installs the Linear integration, any member of your Linear workspace can use it immediately. Team members can assign issues to Steadwing or @mention the bot without any additional setup. Assigning an issue creates a tracked incident in your Steadwing dashboard with full RCA, while @mentioning provides quick analysis in the comment thread. Both methods trigger the same analysis, but assignment offers more detailed tracking and historical data. Yes, but Steadwing will recognize duplicate requests and reference the existing analysis instead of running it twice. Steadwing will post a comment in Linear explaining the failure and update the status to `FAILED`. You can view error details in the Steadwing dashboard or retry by @mentioning the bot again. Currently, analyses cannot be cancelled once started. However, you can track progress in the Steadwing dashboard and receive updates in Linear as the analysis progresses. Yes, Steadwing works with all projects in your workspace, including private projects. The bot respects Linear's permission model. Go to [Settings](https://app.steadwing.com/settings), find the Linear integration, and click **Disconnect**. You should also remove the Steadwing bot from your Linear workspace settings. Currently, Steadwing performs standard RCA. Future updates will support custom analysis parameters. You can provide context in the issue description or comments to guide the analysis. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # Mezmo Source: https://docs.steadwing.com/integrations/mezmo Steadwing connects to your Mezmo account to search and analyze centralized logs during incidents, automatically identifying errors, anomalies, and patterns for root cause analysis. ## What does the Mezmo integration do? The Mezmo integration gives Steadwing read access to your centralized logs so it can automatically search for errors, anomalies, and patterns that correlate with production incidents. During root cause analysis, Steadwing queries your Mezmo data to identify what went wrong without manual log investigation. ## Why Use Mezmo with Steadwing? Access centralized logs from across your entire infrastructure Search logs with powerful query capabilities to find relevant events Identify error patterns and anomalies during incident timeframes Add log context to RCA reports for comprehensive understanding ## How do I connect Mezmo to Steadwing? ### Step 1: Get Mezmo Service Key 1. Log in to your Mezmo dashboard 2. Navigate to **Settings** → **Organization** → **API Keys** 3. Copy your existing service key or create a new one 4. Save the service key securely Keep your service key confidential. It provides access to all logs in your Mezmo account. ### Step 2: Connect Mezmo in Steadwing 1. Navigate to [Steadwing Settings](https://app.steadwing.com/settings) 2. Find the **Mezmo** integration card under **Logs & Search** 3. Click to expand the collapsible form 4. Enter your configuration: * **Mezmo Service Key**: Paste your service key 5. Toggle the switch to **Enable** the integration ## What data does Steadwing pull from Mezmo? ### Data Collection Steadwing queries Mezmo for: * **Application Logs** - Logs from your applications and services * **Infrastructure Logs** - System and platform logs * **Error Events** - Errors and exceptions logged across your stack * **Log Metadata** - Tags, labels, and structured fields ## What permissions does the Mezmo integration need? ### Required Permissions The Mezmo Service Key must have: * **Read access** to logs across your organization * **Search capabilities** to query log data ### Supported Features * Log search across all sources * Structured log field querying * Time-range based log retrieval * Tag and label filtering * Multi-line log aggregation ### Limitations * Historical data limited to Mezmo's retention policy * Rate limits apply based on your Mezmo plan * Large log volumes may affect query performance ## FAQs Steadwing reads log data and metadata for analysis. It does NOT modify logs, create new sources, or change Mezmo configurations. Currently, the service key grants access to all logs in your organization. You can use Mezmo's access control features to manage what logs are available. Steadwing can search logs within your Mezmo retention period, which varies based on your plan. Service keys typically don't expire unless manually revoked. If disconnected, create a new key and update it in Steadwing Settings. Yes, the RCA report includes relevant log excerpts and links to Mezmo for deeper investigation. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # New Relic Source: https://docs.steadwing.com/integrations/newrelic Steadwing pulls APM data, transaction traces, and infrastructure metrics from New Relic to correlate performance issues with production incidents during root cause analysis. ## What does the New Relic integration do? Steadwing connects to New Relic to pull application performance monitoring (APM) data, infrastructure metrics, and transaction traces from your New Relic account. During root cause analysis, Steadwing correlates performance metrics, transaction traces, and infrastructure data with production incidents. ## Why Use New Relic with Steadwing? Analyze application performance metrics and transaction traces Track server metrics, container health, and resource utilization Correlate application errors with incident timing Access real-time performance data during active incidents ## How do I connect New Relic to Steadwing? ### Step 1: Create New Relic API Key 1. Log in to your New Relic account 2. Click on your user menu (bottom left corner) 3. Navigate to **API Keys** * Direct link: [https://one.newrelic.com/api-keys](https://one.newrelic.com/api-keys) 4. Click **Create a key** 5. Configure the key: * **Key type:** User Key * **Name:** Steadwing Integration * **Account:** Select your account * **Notes:** (Optional) API key for Steadwing RCA integration 6. Click **Create a key** 7. Copy the generated API key (starts with `NRAK-`) Save your API key immediately! New Relic only shows it once. If you lose it, you'll need to create a new key. ### Step 2: Identify Your New Relic Region Determine your New Relic region: * **US Datacenter** → Use region: **US** * API endpoint: `api.newrelic.com` * Typical for US-based accounts * **EU Datacenter** → Use region: **EU** * API endpoint: `api.eu.newrelic.com` * For EU-based accounts with data residency requirements If unsure, check your New Relic URL: * `one.newrelic.com` → **US** * `one.eu.newrelic.com` → **EU** ### Step 3: Connect New Relic in Steadwing 1. Navigate to [Steadwing Settings](https://app.steadwing.com/settings) 2. Find the **New Relic** integration card 3. Click to expand the collapsible form 4. Fill in the required fields: * **API Key:** Your New Relic User Key (starts with `NRAK-`) * **Region:** Enter either `US` or `EU` 5. Toggle the switch to **Enable** the integration ## What data does Steadwing pull from New Relic? ### Data Collection Steadwing queries New Relic for: * **APM Metrics** - Application response times, throughput, error rates * **Transaction Traces** - Slow transactions and database queries * **Infrastructure Metrics** - CPU, memory, disk, network usage * **Error Events** - Application exceptions and error details * **Custom Events** - Any custom instrumentation and metrics ### Use Cases **Scenario 1: Slow API Response** * Incident: API endpoint latency increased 5x * Steadwing finds: Database query time spiked in New Relic APM * Analysis: N+1 query pattern introduced in recent deployment * Solution: Optimize queries with proper indexing **Scenario 2: Memory Leak** * Incident: Application instances crashing periodically * Steadwing finds: Gradual memory increase in infrastructure metrics * Analysis: Memory not being released after processing large files * Solution: Implement proper resource cleanup **Scenario 3: Service Dependency Issue** * Incident: User authentication failing intermittently * Steadwing finds: External service call timeout rate increased * Analysis: Third-party auth provider degradation * Solution: Implement circuit breaker and fallback mechanism ## What permissions does the New Relic integration need? ### Required Permissions The New Relic API Key must have: * **metrics\_read** - Read time series metric data * **events\_read** - Read event data and custom events User Keys automatically include these permissions. ## FAQs Use a **User Key** (starts with `NRAK-`). This provides the necessary permissions for reading metrics and events. Do not use Ingest Keys or other key types. Check your New Relic login URL. If you use `one.newrelic.com`, you're on US. If you use `one.eu.newrelic.com`, you're on EU. You can also check in Account Settings. No, Steadwing only has read access. It queries metrics and events but never modifies data, dashboards, alert policies, or configurations. Yes, the RCA report includes charts, transaction traces, and metric summaries that were analyzed during the investigation. The integration will not work. User Keys don't expire automatically, but if revoked or deleted, you'll need to create a new key and update it in Settings. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # PagerDuty Source: https://docs.steadwing.com/integrations/pagerduty Connect PagerDuty to Steadwing so incident timelines, alerts, escalation patterns, and response metrics are automatically pulled into every root cause analysis. ## What does the PagerDuty integration do? The PagerDuty integration feeds incident timelines, alerts, escalation patterns, and response metrics into Steadwing's root cause analysis giving Steadwing the on-call context needed to correlate responder actions with production incidents. During RCA, Steadwing queries your PagerDuty account for relevant incidents, log entries, and custom fields automatically. ## Why Use PagerDuty with Steadwing? Build complete incident timelines with triggers, acknowledgments, and resolutions Connect PagerDuty alerts to monitoring tools like Datadog and Sentry Track time to acknowledge and resolve for incident analysis Understand escalation paths and responder involvement during incidents ## How to connect PagerDuty Connect PagerDuty with an API key so Steadwing can query incident and alert data during root cause analysis. ### Step 1: Create a PagerDuty API Key 1. Log in to your PagerDuty account 2. Navigate to **Integrations** → **Developer Tools** → **API Access Keys** * Direct link: [https://your-subdomain.pagerduty.com/api\_keys](https://your-subdomain.pagerduty.com/api_keys) 3. Click **Create New API Key** 4. Configure the key: * **Description:** Steadwing Integration * **Key Type:** Read-only API Key (recommended) 5. Click **Create Key** 6. Copy the generated API key Save your API key immediately! PagerDuty only shows the key once. Store it securely as it provides access to your incident data. ### Step 2: Connect PagerDuty in Steadwing 1. Navigate to [Steadwing Settings](https://app.steadwing.com/settings) 2. Find the **PagerDuty** integration card 3. Click **Connect via API Key** 4. Fill in the required fields: * **API Key:** Your PagerDuty API key 5. Click **Connect** Using a read-only API key is recommended. Steadwing only needs to read incident data and never modifies your PagerDuty configuration. ## What data does Steadwing pull from PagerDuty? Steadwing queries PagerDuty for: * **Incidents** - Active and recent incidents by time range and status * **Alerts** - Alerts associated with each incident * **Log Entries** - Complete incident timeline including triggers, escalations, and resolutions * **Response Metrics** - Time to acknowledge, time to resolve * **Custom Fields** - Any custom incident field values you've configured ## What permissions does the PagerDuty integration need? The PagerDuty API key requires read access to: * **Incidents** - Read incident data and status * **Alerts** - Read alert details and sources * **Log Entries** - Read incident activity logs ## FAQs A read-only API key is recommended. Steadwing only queries incident data and does not need write access to your PagerDuty account. PagerDuty alerts often contain integration metadata from monitoring tools like Datadog, Sentry, or CloudWatch. Steadwing uses this metadata to correlate incidents across your entire observability stack. No, Steadwing only has read access. Steadwing queries incident data but never acknowledges, resolves, or modifies incidents in PagerDuty. Steadwing queries incidents around the incident timeframe being analyzed, typically including some buffer time before and after to capture related events. Steadwing will lose access to your PagerDuty data. Create a new API key and update it in Steadwing Settings to reconnect. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # Scalyr (DataSet) Source: https://docs.steadwing.com/integrations/scalyr Steadwing connects to your Scalyr (DataSet by SentinelOne) instance to query logs, metrics, and analytical data during incidents, automatically identifying errors, affected services, and error rate trends. ## What does the Scalyr integration do? The Scalyr integration lets Steadwing automatically search your logs for errors, identify affected servers and services, analyze error rate trends, and run complex correlations when an incident triggers. Steadwing queries your Scalyr (DataSet by SentinelOne) logs, metrics, and analytical data so you get root cause analysis without manual log investigation. ## Why Use Scalyr with Steadwing? Search for error logs, exceptions, and warnings around the incident time window Identify affected servers, services, and log sources using facet queries Track error rates and latency over time to pinpoint when degradation began Run PowerQuery analytical queries to group errors by service, status code, or any dimension ## How do I connect Scalyr to Steadwing? ### Step 1: Get Your API Key 1. Log in to your Scalyr instance 2. Navigate to **Settings** → **API Keys** (or visit `https:///keys`) 3. Find or create a **Read Logs** token 4. Copy the token Use a Read Logs token (not Write). Steadwing only needs read access to query your logs during incident analysis. ### Step 2: Connect Scalyr in Steadwing 1. Navigate to [Steadwing Settings](https://app.steadwing.com/settings) 2. Find the **Scalyr (DataSet)** integration card 3. Click to expand the collapsible form 4. Enter your configuration: * **Scalyr API Key** — your Read Logs API token * **Scalyr URL** — your Scalyr instance URL: * US region: `https://app.scalyr.com` * EU region: `https://eu.scalyr.com` * Self-hosted/on-prem: your custom URL (e.g., `https://scalyr.yourcompany.com`) 5. Toggle the switch to **Enable** the integration The integration connects immediately — no OAuth redirect required. ## What data does Steadwing pull from Scalyr? ### Data Collection Steadwing queries Scalyr for: * **Error Logs** - Errors, exceptions, and warnings around the incident timeframe * **Server & Service Impact** - Affected `$serverHost` values, services, and log sources via facet queries * **Error Trends** - Error rates and latency over time to identify degradation onset * **Analytical Queries** - PowerQuery (SQL-like) queries to group and correlate errors by service, status code, or other dimensions ## What permissions does the Scalyr integration need? ### Required Permissions The Scalyr API key must have: * **Read Logs** permission to query log data ### Limitations * Scalyr applies a shared query budget of 30,000ms of server processing time, replenished at 36,000ms/hour * This budget is shared across all API and CLI queries for your account * If rate limits are encountered during RCA, the agent will note partial results in its analysis ## FAQs Steadwing reads log data using Scalyr's query and PowerQuery APIs. It does NOT write, modify, or delete any data in your Scalyr account. US (`app.scalyr.com`), EU (`eu.scalyr.com`), and self-hosted/on-prem instances are all supported. Scalyr's query budget is shared across all API consumers. If limits are reached, Steadwing will note partial results in the RCA report. Check if other tools are consuming the budget. Verify your API key has Read Logs permission and the Scalyr URL matches your region. Verify the Scalyr URL is correct and reachable from your network. Ensure both the API key and URL fields are filled in. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # Sentry Source: https://docs.steadwing.com/integrations/sentry Steadwing pulls error events, stack traces, and performance data from Sentry to correlate them with production incidents during root cause analysis. ## What does the Sentry integration do? Steadwing connects to Sentry to pull error events, stack traces, and performance monitoring data from your Sentry projects. During root cause analysis, Steadwing correlates error patterns, stack traces, and performance issues with production incidents to identify the underlying causes. ## Why use Sentry with Steadwing? Link production errors to specific incidents automatically Analyze error stack traces to identify problematic code paths Detect performance degradation patterns before and during incidents Identify error spikes and anomalies that correlate with incidents ## Connection Methods There are two ways to connect Sentry to Steadwing. You can use one or both together. | Method | Best For | | ---------------------------- | --------------------------------------------- | | **Marketplace App (OAuth)** | Auto-triggering RCA when a Sentry alert fires | | **API Token (Bearer Token)** | Querying Sentry as a data source during RCA | *** ## Method 1: Sentry App (OAuth) Connect the Steadwing Sentry App to enable automatic RCA triggers. Once installed, Steadwing launches root cause analysis the moment a Sentry alert fires no manual intervention needed. Install directly from Steadwing Settings no manual Sentry configuration needed. Steadwing automatically kicks off root cause analysis whenever a Sentry alert fires. Get comprehensive analysis of every alert while filtering out noise. ### Step 1: Install Steadwing from the Sentry Marketplace 1. Go to the **Sentry Marketplace** (Sentry → Settings → Integrations) 2. Search for **Steadwing** and click **Install** 3. Authorize the connection it will redirect you back to Steadwing ### Step 2: Link to your Steadwing organization 1. After the redirect, select your Steadwing organization from the dropdown 2. Click **Complete Setup** 3. The app status will show **App installed** on the Sentry integration card The Sentry App handles webhook delivery automatically. Steadwing receives Sentry alert events without any additional configuration. *** ## Method 2: API Token (Bearer Token) Connect Sentry as a **data source**, allowing Steadwing to query error tracking and performance data during root cause analysis. ### Step 1: Create a Sentry auth token 1. Log in to your Sentry account at [sentry.io](https://sentry.io) 2. Navigate to **Settings** → **Account** → **API** → **Auth Tokens** * Direct link: [https://sentry.io/settings/account/api/auth-tokens/](https://sentry.io/settings/account/api/auth-tokens/) 3. Click **Create New Token** 4. Configure the token: * **Name:** Steadwing Integration * **Scopes:** Select the following permissions: * `org:read` - Read organization information * `project:read` - Read project details * `event:read` - Read error events and issues 5. Click **Create Token** 6. Copy the generated token (it starts with `sntrys_`) Save your token immediately! Sentry only shows it once. If you lose it, you'll need to create a new token. ### Step 2: Connect Sentry in Steadwing 1. Navigate to [Steadwing Settings](https://app.steadwing.com/settings) 2. Find the **Sentry** integration card 3. Click **Connect via API Token** 4. Fill in the required fields: * **Bearer Token:** Your Sentry auth token (starts with `sntrys_`) * **Organization Slug:** Your Sentry organization slug 5. Click **Connect** *** ## What data does Steadwing pull from Sentry? Steadwing queries Sentry for: * **Error Events** - All errors and exceptions logged in your projects * **Issue Details** - Stack traces, error messages, and affected users * **Performance Data** - Transaction traces and slow queries * **Event Metadata** - Tags, breadcrumbs, and environment information ## What permissions does the Sentry integration need? The Sentry auth token must have these scopes: * **org:read** - Read organization and team information * **project:read** - Access project configuration and settings * **event:read** - Read error events, issues, and performance data ### Limitations * Historical data is limited to your Sentry plan's retention period * API rate limits apply based on your Sentry plan tier * Source map access requires separate configuration in Sentry ## FAQs No. The Marketplace App auto-triggers RCA when alerts fire. The API Token lets Steadwing query Sentry as a data source during analysis. Using both together gives you full coverage — automatic triggers plus deep data access. Steadwing reads error events, issues, stack traces, and performance data. Steadwing does NOT access user PII or session replays, and Steadwing never modifies any Sentry data. Yes, when creating the auth token, you can scope it to specific organizations and projects instead of granting global access. Currently, Steadwing supports Sentry SaaS (sentry.io). Self-hosted Sentry support is on our roadmap. Sentry auth tokens do not expire unless manually revoked. If the integration is disconnected, create a new auth token and update it in Steadwing Settings. Yes, the RCA report includes links to relevant Sentry issues, stack traces, and error events that were analyzed. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # SigNoz Source: https://docs.steadwing.com/integrations/signoz Steadwing queries SigNoz for metrics, logs, distributed traces, and alerts to correlate OpenTelemetry observability data with production incidents during root cause analysis. ## What does the SigNoz integration do? Steadwing connects to SigNoz to query metrics, logs, distributed traces, and alerts from your SigNoz instance. During root cause analysis, Steadwing correlates SigNoz observability data with production incidents to identify the underlying causes. ## Why Use SigNoz with Steadwing? Analyze request flows across microservices to identify bottlenecks Correlate system metrics with incidents for deeper insights Search and analyze logs to pinpoint errors and anomalies Link SigNoz alerts to incidents for comprehensive analysis ## How do I connect SigNoz to Steadwing? ### Step 1: Get SigNoz API Key 1. Log in to your SigNoz dashboard 2. Navigate to **Settings** → **Workspace Settings** → **API Key** 3. Copy your existing API key or create a new one 4. Save the API key securely For SigNoz Cloud users, your instance URL will be in the format: `https://ingest.{region}.signoz.cloud` ### Step 2: Connect SigNoz in Steadwing 1. Navigate to [Steadwing Settings](https://app.steadwing.com/settings) 2. Find the **SigNoz** integration card 3. Click to expand the collapsible form 4. Enter your configuration: * **SigNoz URL**: Your SigNoz instance URL (e.g., `https://your-instance.signoz.io` or `https://ingest.{region}.signoz.cloud` for SigNoz Cloud) * **SigNoz API Key**: Paste your API key 5. Toggle the switch to **Enable** the integration ## What data does Steadwing pull from SigNoz? ### Data Collection Steadwing queries SigNoz for: * **Metrics** - System and application metrics (CPU, memory, custom metrics) * **Logs** - Application logs with structured fields and context * **Traces** - Distributed traces showing request flows across services * **Alerts** - Alert history and current alert states ## What permissions does the SigNoz integration need? ### Instance Types **Self-Hosted SigNoz:** * URL format: `https://your-instance.signoz.io` * Requires network access to your instance **SigNoz Cloud:** * URL format: `https://ingest.{region}.signoz.cloud` * Supported regions: `us`, `eu`, `in` ### Supported Features * Metrics monitoring and querying * Log aggregation and search * Distributed trace analysis * Alert history and correlation * Custom dashboards and queries ### Limitations * Historical data limited to SigNoz's retention policy * Rate limits apply based on your SigNoz plan * API key must have read permissions ## FAQs Steadwing reads metrics, logs, traces, and alert data. It does NOT modify any SigNoz data or configurations. Yes, both self-hosted SigNoz and SigNoz Cloud are supported. Make sure to use the correct URL format for your deployment type. The API key needs read access to metrics, logs, traces, and alerts. Write permissions are not required. Immediately revoke the key in SigNoz Settings and create a new one. Update the new key in Steadwing Settings to restore the integration. Yes, the RCA report includes links to relevant traces, metrics, and logs that were analyzed during the investigation. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # Slack Source: https://docs.steadwing.com/integrations/slack Connect Slack to Steadwing so your team receives instant incident alerts and can trigger AI-powered root cause analysis by @mentioning the Steadwing bot in any channel. ## What does the Slack integration do? The Slack integration lets your team receive real-time incident alerts and trigger AI-powered root cause analysis directly from Slack -- without switching tools. Steadwing's Slack bot posts incident notifications, accepts @mention commands to start RCA, and delivers threaded results so your team can collaborate on resolution in the same channel where the alert appeared. ## Why Use Slack with Steadwing? Get immediate alerts when incidents occur in your preferred Slack channel Trigger RCA and manage incidents by simply tagging @Steadwing Keep your entire team informed with threaded incident updates Receive detailed RCA results and solutions directly in Slack threads ## How do I connect Slack to Steadwing? ### Step 1: Connect Slack OAuth 1. Navigate to [Steadwing Settings](https://app.steadwing.com/settings) 2. Find the **Slack** integration card 3. Click the **Connect** button 4. You will be redirected to Slack's authorization page 5. Select the workspace where you want to install Steadwing 6. Click **Allow** to authorize the Steadwing app ### Step 2: Install Steadwing Slack App After completing OAuth, you need to install the Steadwing Slack App in your workspace: 1. Follow the installation link provided in the settings page (Step 2) 2. Select the channels where you want Steadwing to be active 3. Click **Allow** to complete the installation 4. The Steadwing bot will now appear in your selected channels ## How do I use the Slack integration? ### Conversational Follow-up After the RCA is completed, you can continue the conversation with Steadwing by tagging the bot in follow-up messages: * Ask clarifying questions about the root cause * Request additional details about suggested solutions * Inquire about alternative approaches or fixes * Get explanations about specific technical aspects Simply @mention Steadwing in the thread and ask your question. The bot will respond with context-aware answers based on the completed RCA. **Example:** ```text theme={null} Alert: CPU usage at 95% on production server ✅ Steadwing: RCA complete! Found root cause: Recent deployment increased background job frequency └─ Developer: @Steadwing What's the best way to throttle these background jobs? └─ Steadwing: You can implement rate limiting by adding a job queue with concurrency controls... ``` ### Triggering Root Cause Analysis When an alert appears in your Slack channel: 1. Reply to the alert message in a thread 2. Tag `@Steadwing` in your reply 3. Steadwing will acknowledge with a 👀 reaction and post: "Incident created! View it here: \[link]" 4. Once RCA completes, you'll see a ✅ reaction and Steadwing will notify you in the same thread 5. Click the provided link to view detailed results and suggested solutions **Example:** ```text theme={null} Alert: CPU usage at 95% on production server └─ You: @Steadwing please analyze 👀 Steadwing: Incident created! View it here: https://app.steadwing.com/incidents/123 ✅ └─ Steadwing: RCA complete! Found root cause: Recent deployment increased background job frequency ``` ### Receiving Notifications Steadwing will automatically post to your Slack channel when: * An incident is created * RCA analysis is complete * Remediation actions are suggested * Incident status changes ### Automatic Monitoring Bot Analysis Steadwing can automatically analyze error messages from your existing monitoring tools like Sentry, Datadog, or PagerDuty - no @mention needed. **How it works:** When enabled, Steadwing will automatically detect and analyze error messages posted by monitoring bots in channels where the Steadwing bot is installed. Simply enable this feature in your settings, and Steadwing will: * Monitor messages from bot accounts (like Sentry, Datadog, PagerDuty) * Automatically create incidents and perform RCA when errors are detected * Skip human messages and thread replies to focus on new alerts * Process up to 10 bot messages per hour to prevent alert fatigue Automatic monitoring bot analysis means you get instant root cause analysis without having to manually tag @Steadwing every time an alert comes in -- your monitoring tools and Steadwing work together seamlessly. ## What permissions does the Slack integration need? ### Required Permissions The Slack integration requires the following permissions: * `channels:read` - To read channel information * `chat:write` - To send messages and incident updates * `users:read` - To identify team members * `app_mentions:read` - To detect when @Steadwing is mentioned ### Supported Channels * Public channels * Private channels (if Steadwing is explicitly invited) * Shared channels (with limitations) ## FAQs OAuth (Step 1) authorizes Steadwing to access your workspace, but the Slack App installation (Step 2) is required to add the bot to specific channels and enable interactive features. Yes, but you need to explicitly invite the Steadwing bot to private channels using `/invite @Steadwing`. Steadwing only analyzes alerts when explicitly tagged. Untagged alerts will not trigger automatic RCA. Yes, but Steadwing will only create one incident per alert. Subsequent tags on the same alert will reference the existing incident. Go to [Settings](https://app.steadwing.com/settings), find the Slack integration, and click **Disconnect**. You should also uninstall the Steadwing app from your Slack workspace settings. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # Supabase Source: https://docs.steadwing.com/integrations/supabase Steadwing connects to your Supabase projects to monitor database health, connection pools, authentication errors, and service status for AI-powered incident analysis. ## What does the Supabase integration do? Steadwing accesses your Supabase projects, database metrics, and configuration data to diagnose database-related incidents. During root cause analysis, Steadwing investigates database performance issues, connection pool problems, authentication errors, and service health to identify the underlying causes of incidents. ## Why Use Supabase with Steadwing? Monitor PostgreSQL performance, connection pools, and query metrics Track the health status of all Supabase services (Auth, Storage, PostgREST) Analyze database and API configurations to identify misconfigurations Inspect table schemas, functions, and database branches during incidents ## How do I connect Supabase to Steadwing? ### Step 1: Connect Supabase OAuth 1. Navigate to [Steadwing Settings](https://app.steadwing.com/settings) 2. Find the **Supabase** integration card 3. Click the **Connect** button (toggle switch) 4. You will be redirected to Supabase's authorization page 5. Select the organization you want to connect 6. Click **Authorize** to grant Steadwing access to your Supabase projects ## What data does Steadwing pull from Supabase? ### Data Collection Steadwing can query Supabase for: * **Service Health** - Real-time health status of all Supabase services * **Database Metrics** - PostgreSQL configuration, connection pool stats, and performance data * **Project Information** - All projects, branches, and their configurations * **Schema Details** - Table schemas, database functions, and stored procedures * **Storage Data** - Storage buckets and their configurations * **Auth Configuration** - Authentication settings and providers * **Network Settings** - Network restrictions, bans, and security configurations ## Available Capabilities ### Database Management * List all database tables and their schemas * Retrieve database function definitions * Inspect database branches and configurations * View backup history ### Project Configuration * Get PostgreSQL configuration settings * Review PostgREST API configuration * Check PgBouncer connection pooling settings * Analyze authentication configuration ### Service Monitoring * Monitor service health status across all components * Track project upgrade status * Review network restrictions and security settings * Inspect pgsodium encryption configuration ## What permissions does the Supabase integration need? ### Required Permissions The Supabase OAuth integration requires: * **Read access** to your Supabase organization * **Read access** to project configurations * **Read access** to database metadata * **Write access** to database schema operations (index creation, configuration changes) Steadwing does **NOT** have permission to: * Modify user data rows * Delete or create projects * Access sensitive user data Steadwing can execute schema DDL operations (such as creating indexes or altering table configurations) as part of automated remediation, only after user's approval. Steadwing does NOT modify user data rows. ### Supported Features * Service health monitoring * Database configuration analysis * Schema and function inspection * Connection pool monitoring * Authentication configuration review * Storage bucket management * Network security analysis ## FAQs Steadwing reads project configurations, database schemas, service health status, and metadata. It does NOT access your actual database data, user information, or modify any settings. The OAuth flow grants access at the organization level. You can control which projects Steadwing analyzes by managing your Supabase organization permissions. Steadwing can execute approved schema changes like creating indexes or altering table configurations as part of automated remediation. All actions require explicit user approval before execution. Steadwing does not modify user data rows. When an incident occurs, Steadwing queries relevant Supabase metrics and configurations to identify database-related issues like connection pool exhaustion, slow queries, or service degradation. Yes, go to [Settings](https://app.steadwing.com/settings), find the Supabase integration, and click the toggle to disconnect. This will revoke Steadwing's access to your Supabase organization. OAuth tokens are automatically refreshed by Supabase. If the connection is lost, you'll need to reconnect by following the setup instructions again. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # Vercel Source: https://docs.steadwing.com/integrations/vercel Steadwing connects to Vercel to monitor deployments, build logs, and serverless functions, helping you identify deployment-related root causes automatically. ## What does the Vercel integration do? Steadwing accesses deployment logs, build events, and project configurations from your Vercel account to diagnose deployment-related incidents. During root cause analysis, Steadwing investigates deployment failures, build errors, and runtime issues to identify the underlying causes of frontend and deployment problems. ## Why Use Vercel with Steadwing? Track deployment status, failures, and build errors in real-time Analyze complete build logs to identify compilation and dependency issues Monitor runtime logs and errors from deployed applications Inspect project settings, environment variables, and Edge Config ## Connection Methods There are two ways to connect Vercel to Steadwing. You can use one or both together. | Method | Best For | | --------------------------- | -------------------------------------------------------- | | **Marketplace App (OAuth)** | Auto-triggering RCA when a Vercel deployment event fires | | **API Token** | Querying Vercel as a data source during RCA | *** ## Method 1: Marketplace App (OAuth) Install Steadwing directly from the Vercel Marketplace. Once installed, Steadwing automatically launches root cause analysis when Vercel deployment events fire no manual intervention needed. Install Steadwing directly from the Vercel Marketplace no manual configuration needed. Steadwing automatically kicks off root cause analysis on Vercel deployment events. Get comprehensive analysis of every deployment issue while filtering out noise. ### Step 1: Install from the Vercel Marketplace 1. Go to the [Steadwing app on Vercel Marketplace](https://vercel.com/marketplace/steadwing/new) 2. Click **Add Integration** 3. Select the Vercel team or personal account to connect 4. Vercel will redirect you to Steadwing to complete the setup ### Step 2: Link to your Steadwing organization 1. After the redirect, select your Steadwing organization from the dropdown 2. Click **Connect** to link the Vercel installation to your organization 3. The app status will show **App installed** on your Vercel integration card in Steadwing Settings The Marketplace App handles webhook delivery. Steadwing receives Vercel deployment events automatically without any additional configuration. *** ## Method 2: API Token Connect Vercel as a **data source**, allowing Steadwing to query deployment and build data during root cause analysis. ### Step 1: Create Vercel API Token 1. Log in to your Vercel account at [vercel.com](https://vercel.com) 2. Navigate to **Settings** → **Tokens** * Direct link: [https://vercel.com/account/tokens](https://vercel.com/account/tokens) 3. Click **Create Token** 4. Configure the token: * **Token Name:** Steadwing Integration * **Scope:** Select the team/account you want to monitor * **Expiration:** Choose an appropriate expiration period (or no expiration) 5. Click **Create Token** 6. Copy the generated token immediately Save your token immediately! Vercel only shows it once. If you lose it, you'll need to create a new token. ### Step 2: Connect Vercel in Steadwing 1. Navigate to [Steadwing Settings](https://app.steadwing.com/settings) 2. Find the **Vercel** integration card 3. Click **Connect via API Token** 4. Fill in the required fields: * **API Token:** Your Vercel API token 5. Click **Connect** *** ## What data does Steadwing pull from Vercel? Steadwing can query Vercel for: * **Deployments** - All deployments across your projects with status and timing * **Build Logs** - Complete build output including errors and warnings * **Runtime Logs** - Application logs from deployed functions and pages * **Deployment Events** - Lifecycle events (queued, building, ready, error, canceled) * **Deployment Checks** - Automated checks and their pass/fail status * **Project Information** - Project configurations, settings, and metadata * **Edge Config** - Feature flags and configuration values * **Domain Aliases** - Custom domains and routing configuration ## Available Capabilities ### Deployment Analysis * List all deployments with filtering by project, status, and time * Get detailed deployment information including build configuration * Retrieve complete build logs with error highlighting * Track deployment events and state transitions * Review automated deployment checks and results ### Project Management * List all projects in your Vercel account * Get project configuration and settings * Review environment variables (names only, not values) * Inspect build and output settings ### Edge Configuration * List Edge Configs for feature flags and dynamic configuration * Get specific Edge Config items and their values * Review Edge Config tokens and access controls ### Team & Access * List teams and their members * Review authentication tokens (metadata only) * Check domain aliases and routing ## What permissions does the Vercel integration need? The Vercel API token requires: * **Read access** to deployments and build logs * **Read access** to project configurations * **Read access** to Edge Config (if used) * **Create deployments** — trigger redeployments as part of automated remediation Steadwing does **NOT** have permission to: * Change project settings * Delete resources * Access environment variable values (only names) * Modify Edge Config values Write access to deployments is required for Steadwing to trigger redeployments as part of automated remediation, only after user's approval. ### Token Scopes When creating your token, you can limit access to: * Specific teams or personal account * Specific projects (via team selection) ## FAQs No. The Marketplace App auto-triggers RCA on deployment events. The API Token lets Steadwing query Vercel as a data source during analysis. Using both together gives you full coverage — automatic triggers plus deep data access. Steadwing reads deployment logs, build outputs, project configurations, and Edge Config. It does NOT access environment variable values, source code, or modify any settings. Yes, when creating the API token, select a specific team scope. This limits access to only that team's projects. Yes, Steadwing can trigger redeployments as an automated remediation action when approved by the user. All deployment actions require explicit user approval before execution. When a deployment-related incident occurs, Steadwing queries deployment logs, build errors, and configuration to identify issues like failed builds, missing dependencies, or environment problems. If your token expires or is revoked, the API Token connection will stop working. Create a new token and update it in Steadwing Settings to reconnect. No, Steadwing can only see environment variable names, not their values. This protects sensitive credentials and secrets. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # Node.js SDK Source: https://docs.steadwing.com/node-sdk Install the Steadwing Node SDK to auto-capture exceptions, error logs, and HTTP breadcrumbs from your Node.js applications and send them to Steadwing for AI-powered root cause analysis. ## What is the Steadwing Node SDK? The Steadwing Node SDK auto-captures exceptions, error logs, and HTTP breadcrumbs from your Node.js applications and sends them to Steadwing for root cause analysis. Add two lines of code and Steadwing starts monitoring your application no manual instrumentation required. Unhandled exceptions, rejections, and error logs captured automatically Outgoing HTTP/HTTPS requests recorded with method, URL, status, and duration Route error capture with full request context Sensitive request header fields redacted before sending ## Installation ```bash theme={null} npm install @steadwing/node ``` Requires Node.js 18+. View on [npm](https://www.npmjs.com/package/@steadwing/node) or browse the [source on GitHub](https://github.com/steadwing/steadwing-node). ## Quick Start Get your API key from [app.steadwing.com/organization](https://app.steadwing.com/organization), then initialize the SDK: ```javascript theme={null} const steadwing = require("@steadwing/node"); steadwing.init({ apiKey: "st_your_api_key" }); ``` That's it. The SDK automatically: * Captures unhandled exceptions (`uncaughtException`) * Captures unhandled promise rejections (`unhandledRejection`) * Captures `console.error()`, winston, and pino error-level logs * Records outgoing HTTP/HTTPS requests as breadcrumbs * Sends heartbeats every 60 seconds ## Configuration ```javascript theme={null} steadwing.init({ apiKey: "st_...", // Required: your API key service: "my-service", // Optional: defaults to "default" env: "PROD", // Optional: defaults to "PROD" enabled: true, // Optional: set false to disable }); ``` Only events sent with `env="PROD"` are considered for auto-monitoring. Events from other environments are received but will not trigger automated RCA. ## Manual Capture For cases where you want to explicitly report errors or messages: ```javascript theme={null} const steadwing = require("@steadwing/node"); // Capture a specific exception try { riskyOperation(); } catch (err) { steadwing.captureException(err); } ``` ```javascript theme={null} const steadwing = require("@steadwing/node"); steadwing.captureMessage("Deployment completed", "info"); ``` ## What Gets Captured ### Exceptions | Data | Description | | --------------- | ------------------------------------------------------- | | Stack trace | Full V8 stack trace with file, line, and column | | Exception chain | `Error.cause` chain included | | Breadcrumbs | Last 100 events leading up to the error | | Request context | Method, path, headers (when using framework middleware) | ### Logs * `console.error()` sent as events * Winston error/crit/emerg-level logs sent as events * Pino error/fatal-level logs sent as events * All log levels recorded as breadcrumbs for context ### HTTP Breadcrumbs Every outgoing HTTP/HTTPS request is recorded with: * Method and URL * Response status code * Request duration * Rolling buffer of last 100 entries ## Data Scrubbing Built-in redaction covers selected structured fields. For supported framework integrations (Express, Fastify), the SDK replaces values whose exact field name matches the list below (case-insensitive) in captured request headers. ``` password, passwd, secret, api_key, apikey, token, auth, authorization, cookie, csrf, session, credit_card, ssn ``` Redaction does **not** scan free-text logs, exception messages, stack traces, URLs or query strings, SQL, or values embedded inside strings. If your application may include sensitive data in these contexts, implement additional scrubbing at the application level before the data reaches Steadwing. ## Framework Support | Framework | What's Captured | | ----------- | -------------------------------------------------------------- | | **Express** | Route errors with full request context (method, path, headers) | | **Fastify** | Route errors with request context via onError hook | | **winston** | Error-level log capture (auto-detected) | | **pino** | Error-level log capture (auto-detected) | ### Express Add the error handler as your last middleware: ```javascript theme={null} const steadwing = require("@steadwing/node"); const express = require("express"); steadwing.init({ apiKey: "st_..." }); const app = express(); app.get("/", (req, res) => res.send("ok")); app.get("/fail", (req, res, next) => next(new Error("DB timeout"))); // Add as the last middleware app.use(steadwing.expressErrorHandler()); app.listen(3000); ``` ### Fastify Register the plugin on your Fastify instance: ```javascript theme={null} const steadwing = require("@steadwing/node"); const fastify = require("fastify"); steadwing.init({ apiKey: "st_..." }); const app = fastify(); app.register(steadwing.fastifyErrorHandler()); app.listen({ port: 3000 }); ``` Winston and pino are captured automatically when installed, no extra code needed. ## TypeScript Full TypeScript support with exported types: ```typescript theme={null} import { init, captureException, expressErrorHandler } from "@steadwing/node"; import type { SteadwingConfig } from "@steadwing/node"; const config: SteadwingConfig = { apiKey: "st_...", service: "my-service", }; init(config); ``` ## FAQs No. After calling `steadwing.init()`, the SDK hooks into Node's exception handling, console, and HTTP modules automatically. For Express/Fastify request context, add one line of middleware. Minimal. Events are batched and sent every 5 seconds in a non-blocking flush. Breadcrumbs are stored in a fixed-size buffer. Timers use `unref()` so the SDK never keeps your process alive. Yes. Pass `enabled: false` to `steadwing.init()` and the SDK becomes a no-op, no patches are installed and no events are sent. The SDK coexists with other error trackers. It listens on `process.on('uncaughtException')` and patches `console.error` without removing existing listeners or handlers. Selected request header fields are scrubbed before transmission. Data is sent over HTTPS to Steadwing's backend. See the Data Scrubbing section for details on what is and isn't covered. Need help? Contact us at [hello@steadwing.com](mailto:hello@steadwing.com) # CrewAI Source: https://docs.steadwing.com/plugins/crewai OpenAlerts monitors your CrewAI agents in real-time, detecting LLM errors, stuck agents, token blowups, and tool failures instantly with a live dashboard and Slack/Discord/webhook alerts. [CrewAI](https://github.com/crewAIInc/crewAI) is an open-source AI agent framework for orchestrating role-playing autonomous agents that collaborate to solve complex tasks through structured crews, agents, and task assignments. ## How do I install CrewAI? ```bash theme={null} theme={null} pip install crewai ``` See the [CrewAI documentation](https://docs.crewai.com) for details. ## How do I set up OpenAlerts for CrewAI? AI agents fail silently — LLM errors, stuck sessions, token blowups — nobody knows until a user complains. [OpenAlerts](https://github.com/steadwing/openalerts) watches your agent in real-time and alerts you the moment something goes wrong. ### Install ```bash theme={null} theme={null} pip install openalerts ``` Add `openalerts.init` before your crew runs — everything is monitored automatically from that point: ```python theme={null} theme={null} import asyncio import openalerts from crewai import Agent, Task, Crew async def main(): await openalerts.init({"framework": "crewai"}) researcher = Agent( role="Researcher", goal="Research topics thoroughly", backstory="You are an expert researcher.", llm="gpt-4o-mini", ) task = Task( description="Research the benefits of AI monitoring", expected_output="A short summary", agent=researcher, ) crew = Crew(agents=[researcher], tasks=[task]) result = crew.kickoff() print(result) asyncio.run(main()) ``` The CrewAI adapter uses CrewAI's native event bus — no monkey-patching. Every crew run, agent execution, task step, tool call, and LLM call is tracked automatically with full session correlation (Crew = session, Agent = subagent, Task = step). Cleanup runs on exit. Events are persisted to `~/.openalerts/` as JSONL. To receive alerts on Slack, Discord, or a custom webhook, pass channels in the init config: ```python theme={null} theme={null} await openalerts.init({ "channels": [ {"type": "slack", "webhook_url": "https://hooks.slack.com/services/..."}, {"type": "discord", "webhook_url": "https://discord.com/api/webhooks/..."}, {"type": "webhook", "webhook_url": "https://your-server.com/alerts"}, ] }) ``` Or set environment variables instead (no code changes needed): ```bash theme={null} theme={null} OPENALERTS_SLACK_WEBHOOK_URL="https://hooks.slack.com/services/..." OPENALERTS_DISCORD_WEBHOOK_URL="https://discord.com/api/webhooks/..." OPENALERTS_WEBHOOK_URL="https://your-server.com/alerts" ``` ### Alert Rules 7 rules run against every event in real-time. All thresholds and cooldowns are configurable. | Rule | Watches for | Severity | Default threshold | | -------------------- | --------------------------------------- | -------- | ----------------- | | `llm-errors` | LLM/agent failures in 1 min window | ERROR | 1 error | | `tool-errors` | Tool execution failures in 1 min window | WARN | 1 error | | `agent-stuck` | Agent idle too long | WARN | 2 min | | `token-limit` | Token limit exceeded | ERROR | - | | `step-limit-warning` | Agent reaches 80% of max\_steps | WARN | - | | `high-error-rate` | Failure rate over last 20 calls | ERROR | 50% | | `subagent-errors` | Subagent failures in 1 min window | WARN | 1 error | Every rule also accepts `enabled` (default `true`) and `cooldown_seconds` (default `900`). To tune rules: ```python theme={null} theme={null} await openalerts.init({ "channels": [...], "rules": { "llm-errors": {"threshold": 5}, "high-error-rate": {"enabled": False}, "tool-errors": {"cooldown_seconds": 1800}, }, "cooldown_seconds": 900, "max_alerts_per_hour": 5, }) ``` Set `"quiet": True` for log-only mode (no alerts sent to channels). ### Dashboard A real-time web dashboard starts automatically at [http://localhost:9464/openalerts](http://localhost:9464/openalerts): | Tab | What it shows | | ------------ | ----------------------------------------------------------------- | | **Activity** | Step-by-step execution timeline with tool calls, LLM usage, costs | | **Health** | Rule status, alert history, system stats | | **Debug** | State snapshot for troubleshooting | By default, the dashboard runs in-process and stops when your agent exits. For a persistent dashboard, run `openalerts serve` in a separate terminal and disable the in-process one with `"dashboard": False`. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # nanobot Source: https://docs.steadwing.com/plugins/nanobot OpenAlerts monitors your nanobot agents in real-time, detecting LLM errors, stuck agents, token blowups, subagent failures, and tool errors instantly with a live dashboard and Slack/Discord/webhook alerts. [nanobot](https://github.com/HKUDS/nanobot) is an open-source AI agent framework for building lightweight, composable agents with support for subagent orchestration, tool execution, and multi-step task handling. ## How do I install nanobot? ```bash theme={null} theme={null} git clone https://github.com/HKUDS/nanobot.git cd nanobot pip install -e . ``` See the [nanobot README](https://github.com/HKUDS/nanobot) for details. ## How do I set up OpenAlerts for nanobot? AI agents fail silently — LLM errors, stuck sessions, token blowups — nobody knows until a user complains. [OpenAlerts](https://github.com/steadwing/openalerts) watches your agent in real-time and alerts you the moment something goes wrong. ### Install ```bash theme={null} theme={null} pip install openalerts ``` Add `openalerts.init` before your agent runs — everything is monitored automatically from that point: ```python theme={null} theme={null} import asyncio import openalerts from nanobot.agent.loop import AgentLoop from nanobot.bus.queue import MessageBus from nanobot.providers.litellm_provider import LiteLLMProvider async def main(): await openalerts.init({"framework": "nanobot"}) provider = LiteLLMProvider(api_key="sk-...", default_model="gpt-4o-mini") agent = AgentLoop( bus=MessageBus(), provider=provider, workspace="./workspace", ) response = await agent.process_direct("Research quantum computing") print(response) asyncio.run(main()) ``` OpenAlerts patches nanobot internals so every LLM call, tool execution, agent step, and error flows through the monitoring engine automatically. The nanobot adapter also tracks **subagent lifecycle** — `subagent.spawn`, `subagent.end`, and `subagent.error` events are captured automatically when `SubagentManager` is used, with parent/child session correlation. Cleanup runs on exit. Events are persisted to `~/.openalerts/` as JSONL. To receive alerts on Slack, Discord, or a custom webhook, pass channels in the init config: ```python theme={null} theme={null} await openalerts.init({ "channels": [ {"type": "slack", "webhook_url": "https://hooks.slack.com/services/..."}, {"type": "discord", "webhook_url": "https://discord.com/api/webhooks/..."}, {"type": "webhook", "webhook_url": "https://your-server.com/alerts"}, ] }) ``` Or set environment variables instead (no code changes needed): ```bash theme={null} theme={null} OPENALERTS_SLACK_WEBHOOK_URL="https://hooks.slack.com/services/..." OPENALERTS_DISCORD_WEBHOOK_URL="https://discord.com/api/webhooks/..." OPENALERTS_WEBHOOK_URL="https://your-server.com/alerts" ``` ### Alert Rules 7 rules run against every event in real-time. All thresholds and cooldowns are configurable. | Rule | Watches for | Severity | Default threshold | | -------------------- | --------------------------------------- | -------- | ----------------- | | `llm-errors` | LLM/agent failures in 1 min window | ERROR | 1 error | | `tool-errors` | Tool execution failures in 1 min window | WARN | 1 error | | `agent-stuck` | Agent idle too long | WARN | 2 min | | `token-limit` | Token limit exceeded | ERROR | - | | `step-limit-warning` | Agent reaches 80% of max\_steps | WARN | - | | `high-error-rate` | Failure rate over last 20 calls | ERROR | 50% | | `subagent-errors` | Subagent failures in 1 min window | WARN | 1 error | Every rule also accepts `enabled` (default `true`) and `cooldown_seconds` (default `900`). To tune rules: ```python theme={null} theme={null} await openalerts.init({ "channels": [...], "rules": { "llm-errors": {"threshold": 5}, "high-error-rate": {"enabled": False}, "tool-errors": {"cooldown_seconds": 1800}, }, "cooldown_seconds": 900, "max_alerts_per_hour": 5, }) ``` Set `"quiet": True` for log-only mode (no alerts sent to channels). ### Dashboard A real-time web dashboard starts automatically at [http://localhost:9464/openalerts](http://localhost:9464/openalerts): | Tab | What it shows | | ------------ | ----------------------------------------------------------------- | | **Activity** | Step-by-step execution timeline with tool calls, LLM usage, costs | | **Health** | Rule status, alert history, system stats | | **Debug** | State snapshot for troubleshooting | By default, the dashboard runs in-process and stops when your agent exits. For a persistent dashboard, run `openalerts serve` in a separate terminal and disable the in-process one with `"dashboard": False`. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # OpenClaw Source: https://docs.steadwing.com/plugins/openclaw OpenAlerts monitors your OpenClaw AI messaging gateway in real-time, detecting LLM errors, gateway outages, stuck sessions, and cost spikes with a live dashboard and Telegram/webhook alerts. [OpenClaw](https://github.com/openclaw/openclaw) is an open-source AI messaging gateway that connects to WhatsApp, Telegram, Discord, Slack, iMessage, and other messaging channels. It routes conversations to your AI agents and includes a plugin system for extending functionality. ## How do I install OpenClaw? ```bash theme={null} theme={null} npm install -g openclaw@latest # Run the interactive setup wizard openclaw onboard --install-daemon ``` See the [OpenClaw getting started guide](https://docs.openclaw.ai/start/getting-started) for details. ## How do I set up OpenAlerts for OpenClaw? AI agents fail silently — LLM errors, stuck sessions, gateway outages — nobody knows until a user complains. [OpenAlerts](https://github.com/steadwing/openalerts) is a standalone monitoring daemon that connects to your OpenClaw gateway in real-time, fires alerts when something goes wrong, and serves a live dashboard. No code changes to OpenClaw needed — runs as a separate process alongside it. ### Install ```bash theme={null} theme={null} npm install -g @steadwing/openalerts ``` Requires **Node.js 22.5.0 or later** — uses the built-in `node:sqlite` module, so there are no native builds or binaries to compile. ### Quick Start ```bash theme={null} theme={null} # 1. Create default config (auto-detects your OpenClaw gateway token) openalerts init # 2. Edit config to add your alert channel # ~/.openalerts/config.json # 3. Start monitoring openalerts start ``` Dashboard opens at **[http://127.0.0.1:4242](http://127.0.0.1:4242)** — the gateway overlay dismisses automatically once connected. The gateway token is auto-detected from `gateway.auth.token` in `~/.openclaw/openclaw.json` — no manual copy needed. ### Channels Configure at least one channel in `~/.openalerts/config.json`. Falls back to `console` if none are set. ```json theme={null} theme={null} { "channels": [ { "type": "telegram", "token": "BOT_TOKEN", "chatId": "CHAT_ID" }, { "type": "webhook", "webhookUrl": "https://your-endpoint" }, { "type": "console" } ] } ``` ### Alert Rules 10 rules run against every event in real-time. All thresholds and cooldowns are configurable. | Rule | Triggers when | Default threshold | Default cooldown | | ------------------- | --------------------------------------- | ----------------- | ---------------- | | `infra-errors` | Infrastructure errors in 1 min window | 1 | 15 min | | `llm-errors` | LLM/agent errors in 1 min window | 1 | 15 min | | `tool-errors` | Tool execution failures in 1 min window | 1 | 15 min | | `heartbeat-fail` | Consecutive heartbeat failures | 3 | 30 min | | `session-stuck` | Session idle too long | 120s | 30 min | | `high-error-rate` | Error rate of last 20 calls | 50% | 30 min | | `queue-depth` | Items piling up in delivery queue | 10 | 15 min | | `gateway-down` | No heartbeat from watchdog | 30s | 60 min | | `cost-hourly-spike` | LLM cost per hour | \$5 | 30 min | | `cost-daily-budget` | LLM cost per day | \$20 | 6 h | To tune rules: ```json theme={null} theme={null} { "rules": { "llm-errors": { "threshold": 5 }, "gateway-down": { "enabled": false }, "heartbeat-fail": { "cooldownMinutes": 60 } } } ``` Set `"quiet": true` at the top level for log-only mode (no alerts sent). ### Dashboard A real-time web dashboard is served at **[http://127.0.0.1:4242](http://127.0.0.1:4242)** after running `openalerts start`: | Tab | What it shows | | ------------------ | ---------------------------------------------------------------- | | **Overview** | Gateway health log, live activity feed, 24h stats, recent alerts | | **Workspaces** | Per-agent SOUL.md, HEARTBEAT.md, MEMORY.md previews | | **Alerts** | Full alert history with severity, rule ID, fingerprint | | **Sessions** | Active sessions with status, token counts, cost | | **Live Monitor** | Real-time per-run timeline — steps, tool calls, LLM responses | | **Cron Jobs** | Scheduled job status, last/next run, consecutive errors | | **Diagnostics** | Raw engine event log | | **Delivery Queue** | Pending/failed alert delivery items | ### CLI | Command | Description | | ------------------- | ---------------------------------------------------- | | `openalerts init` | Create default config at `~/.openalerts/config.json` | | `openalerts start` | Start the monitoring daemon | | `openalerts status` | Print live engine state (daemon must be running) | | `openalerts test` | Fire a test alert through all configured channels | `openalerts start` accepts `--port N` (default `4242`) and `--config PATH` (default `~/.openalerts/config.json`). Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # OpenManus Source: https://docs.steadwing.com/plugins/openmanus OpenAlerts monitors your OpenManus agents in real-time, detecting LLM errors, stuck agents, token blowups, and tool failures instantly with a live dashboard and Slack/Discord/webhook alerts. [OpenManus](https://github.com/FoundationAgents/OpenManus) is an open-source AI agent framework for building general-purpose agents that can browse the web, write code, execute tools, and handle multi-step tasks autonomously. ## How do I install OpenManus? ```bash theme={null} theme={null} git clone https://github.com/FoundationAgents/OpenManus.git cd OpenManus pip install -e . ``` See the [OpenManus README](https://github.com/FoundationAgents/OpenManus) for details. ## How do I set up OpenAlerts for OpenManus? AI agents fail silently — LLM errors, stuck sessions, token blowups — nobody knows until a user complains. [OpenAlerts](https://github.com/steadwing/openalerts) watches your agent in real-time and alerts you the moment something goes wrong. ### Install ```bash theme={null} theme={null} pip install openalerts ``` Add `openalerts.init` before your agent runs — everything is monitored automatically from that point: ```python theme={null} theme={null} import asyncio import openalerts from app.agent.manus import Manus async def main(): await openalerts.init({}) agent = Manus() await agent.run("Research quantum computing") asyncio.run(main()) ``` OpenAlerts patches OpenManus internals (`BaseAgent.run`, `ReActAgent.step`, `ToolCallAgent.execute_tool`, `LLM.ask_tool`, `LLM.ask`) so every LLM call, tool execution, agent step, and error flows through the monitoring engine automatically. Cleanup runs on exit. Events are persisted to `~/.openalerts/` as JSONL. To receive alerts on Slack, Discord, or a custom webhook, pass channels in the init config: ```python theme={null} theme={null} await openalerts.init({ "channels": [ {"type": "slack", "webhook_url": "https://hooks.slack.com/services/..."}, {"type": "discord", "webhook_url": "https://discord.com/api/webhooks/..."}, {"type": "webhook", "webhook_url": "https://your-server.com/alerts"}, ] }) ``` Or set environment variables instead (no code changes needed): ```bash theme={null} theme={null} OPENALERTS_SLACK_WEBHOOK_URL="https://hooks.slack.com/services/..." OPENALERTS_DISCORD_WEBHOOK_URL="https://discord.com/api/webhooks/..." OPENALERTS_WEBHOOK_URL="https://your-server.com/alerts" ``` ### Alert Rules 6 rules run against every event in real-time. All thresholds and cooldowns are configurable. | Rule | Watches for | Severity | Default threshold | | -------------------- | --------------------------------------- | -------- | ----------------- | | `llm-errors` | LLM/agent failures in 1 min window | ERROR | 1 error | | `tool-errors` | Tool execution failures in 1 min window | WARN | 1 error | | `agent-stuck` | Agent idle too long | WARN | 2 min | | `token-limit` | Token limit exceeded | ERROR | - | | `step-limit-warning` | Agent reaches 80% of max\_steps | WARN | - | | `high-error-rate` | Failure rate over last 20 calls | ERROR | 50% | Every rule also accepts `enabled` (default `true`) and `cooldown_seconds` (default `900`). To tune rules: ```python theme={null} theme={null} await openalerts.init({ "channels": [...], "rules": { "llm-errors": {"threshold": 5}, "high-error-rate": {"enabled": False}, "tool-errors": {"cooldown_seconds": 1800}, }, "cooldown_seconds": 900, "max_alerts_per_hour": 5, }) ``` Set `"quiet": True` for log-only mode (no alerts sent to channels). ### Dashboard A real-time web dashboard starts automatically at [http://localhost:9464/openalerts](http://localhost:9464/openalerts): | Tab | What it shows | | ------------ | ----------------------------------------------------------------- | | **Activity** | Step-by-step execution timeline with tool calls, LLM usage, costs | | **Health** | Rule status, alert history, system stats | | **Debug** | State snapshot for troubleshooting | By default, the dashboard runs in-process and stops when your agent exits. For a persistent dashboard, run `openalerts serve` in a separate terminal and disable the in-process one with `"dashboard": False`. Need additional help? Please reach out to us at [hello@steadwing.com](mailto:hello@steadwing.com) # Python SDK Source: https://docs.steadwing.com/python-sdk Install the Steadwing Python SDK to auto-capture exceptions, error logs, and HTTP breadcrumbs from your Python applications and send them to Steadwing for AI-powered root cause analysis. ## What is the Steadwing Python SDK? The Steadwing Python SDK auto-captures exceptions, error logs, and HTTP breadcrumbs from your Python applications and sends them to Steadwing for root cause analysis. Add two lines of code and Steadwing starts monitoring your application no manual instrumentation required. Unhandled exceptions, error logs, and thread crashes captured automatically Outgoing HTTP requests recorded with method, URL, status, and duration Automatic route error capture with request context when FastAPI is installed Sensitive request header and variable fields redacted before sending ## Installation ```bash theme={null} pip install steadwing ``` Requires Python 3.10+. View on [PyPI](https://pypi.org/project/steadwing/) or browse the [source on GitHub](https://github.com/steadwing/steadwing-python). ## Quick Start Get your API key from [app.steadwing.com/organization](https://app.steadwing.com/organization), then initialize the SDK: ```python theme={null} import steadwing steadwing.init( api_key="st_your_api_key" ) ``` That's it. The SDK automatically: * Captures unhandled exceptions (including in threads) * Captures `logging.error()` and `logging.critical()` calls * Records outgoing HTTP requests as breadcrumbs * Sends heartbeats every 60 seconds * Patches supported frameworks to capture route errors with request context ## Configuration ```python theme={null} steadwing.init( api_key="st_...", # Required: your API key service="my-service", # Optional: defaults to "default" env="PROD", # Optional: defaults to "PROD" enabled=True, # Optional: set False to disable ) ``` Only events sent with `env="PROD"` are considered for auto-monitoring. Events from other environments are received but will not trigger automated RCA. ## What Gets Captured ### Exceptions | Data | Description | | --------------- | ------------------------------------------------ | | Stack trace | Full trace with local variables | | Exception chain | `__cause__` and `__context__` included | | Breadcrumbs | Last 100 events leading up to the error | | Request context | Method, path, headers (for web framework routes) | ### Logs * `logging.error()` and `logging.critical()` are sent as events * All log levels are recorded as breadcrumbs for context ### HTTP Breadcrumbs Every outgoing HTTP request is recorded with: * Method and URL * Response status code * Request duration * Rolling buffer of last 100 entries ## Data Scrubbing Built-in redaction covers selected structured fields. For supported framework integrations (FastAPI, Django, Flask), the SDK replaces values whose exact field name matches the list below (case-insensitive) in captured request headers. Python also applies this rule to traceback-local variable names. ``` password, passwd, secret, api_key, apikey, token, auth, authorization, cookie, csrf, session, credit_card, ssn ``` Redaction does **not** scan free-text logs, exception messages, stack traces, URLs or query strings, SQL, or values embedded inside strings. If your application may include sensitive data in these contexts, implement additional scrubbing at the application level before the data reaches Steadwing. ## Framework Support The SDK auto-detects installed frameworks and patches them automatically. No extra configuration needed. | Framework | What's Captured | | -------------- | -------------------------------------------------------------- | | **FastAPI** | Route errors with full request context (method, path, headers) | | **Django** | Middleware-based exception capture with request metadata | | **Flask** | Error handler integration with request context | | **SQLAlchemy** | Database query breadcrumbs (query, duration) | | **Django ORM** | Database query breadcrumbs via cursor wrapper | | **asyncio** | Unhandled exceptions in async tasks and event loops | ## FAQs No. After calling `steadwing.init()`, the SDK hooks into Python's exception handling and logging system automatically. Minimal. Events are sent asynchronously and the SDK adds negligible overhead to your application. Breadcrumbs are stored in a fixed-size ring buffer. Yes. Pass `enabled=False` to `steadwing.init()` and the SDK becomes a no-op no patches are installed and no events are sent. The SDK coexists with other error trackers. It hooks into `sys.excepthook` and the logging module without interfering with other handlers. Selected request header and local-variable fields are scrubbed before transmission. Data is sent over HTTPS to Steadwing's backend. See the Data Scrubbing section for details on what is and isn't covered. Need help? Contact us at [hello@steadwing.com](mailto:hello@steadwing.com) # Quick Setup Guide Source: https://docs.steadwing.com/quick-setup Create a Steadwing account, connect GitHub and Slack via OAuth, and trigger your first AI-powered root cause analysis — all in under 5 minutes with no agents to deploy. ## How do I set up Steadwing? Sign up with Google OAuth, connect your tools, and trigger your first root cause analysis — all in under 5 minutes. No agents to deploy, no code changes required. Create your account at [app.steadwing.com](https://app.steadwing.com) using Google OAuth. No credit card required. Enter your organization name and invite team members. Admins can manage the org, members can investigate incidents - everyone stays in sync. Connect your tools via OAuth in [Settings](https://app.steadwing.com/settings). For best results, connect: * **GitHub** (required) - For code change correlation * **One alerting/observability tool** - Datadog, Sentry, New Relic, PagerDuty, or similar All integrations use OAuth - connect in clicks, not hours. You're ready! Trigger your first RCA from Slack, Linear, or paste any error directly into Steadwing. ## Which integrations should I connect first? For the best root cause analysis, connect these integrations: **Required** - Correlate incidents with code changes, deployments, and releases Trigger RCA by @mentioning Steadwing in any alert thread Pull metrics, monitors, and APM data during analysis Connect cloud infrastructure for resource and service insights **Start simple**: Connect GitHub + Slack + your primary observability tool. You can add more integrations later as needed. ## How to Trigger RCA Once setup is complete, you have three ways to trigger root cause analysis: ### From Slack 1. When an alert fires in your Slack channel, reply to the message 2. Tag `@Steadwing` in your reply 3. Steadwing acknowledges and starts the RCA in the background 4. Once complete, Steadwing posts results in the same thread with a link to the full analysis Screenshot showing how to trigger Steadwing RCA in Slack: a user replies to an alert message with @Steadwing, and Steadwing responds with a link to the root cause analysis results. > **Image description:** A Slack thread where a monitoring alert appears, a team member replies with `@Steadwing`, and the Steadwing bot responds with an acknowledgment emoji and a link to the full RCA report. ### From Linear 1. Create or find an issue related to an incident 2. Either assign the issue to Steadwing, or @mention Steadwing in a comment 3. Steadwing performs RCA and posts results directly in Linear ### Paste an Error 1. Go to your [Steadwing Dashboard](https://app.steadwing.com) 2. Paste any error message, stack trace, or alert text 3. Steadwing analyzes it and generates the RCA ## How do I use Steadwing in my IDE? Use Steadwing directly in your IDE via the [MCP Server](/steadwing-mcp). The MCP server works with Claude Code, Cursor, and other MCP-compatible tools. * Analyze local code without GitHub authentication * Get RCA insights directly in your development environment * Enhanced performance when integrations are connected Install from [Smithery](https://smithery.ai/server/@steadwing/mcp) and start analyzing code in minutes. ## What Happens Next? After your first RCA, Steadwing starts learning from your incident history. Each incident makes the next one faster and more accurate. You'll get: * **Instant RCA** when alerts fire * **Evidence from all connected sources** - logs, metrics, traces, code changes * **Short-term and long-term solutions** ready for approval * **Conversational follow-up** - ask questions about any incident ## Need Help? * Check our [Integrations](/integrations) page for detailed setup guides * Visit the [MCP Server](/steadwing-mcp) page for IDE integration * Contact us at [hello@steadwing.com](mailto:hello@steadwing.com) for support # MCP Server for IDEs Source: https://docs.steadwing.com/steadwing-mcp Install the Steadwing MCP server to run root cause analysis and investigate code issues directly from Cursor, Claude Desktop, Smithery, or any MCP-compatible client without switching to a browser. ## What is the Steadwing MCP server? The Steadwing MCP server brings AI-powered root cause analysis directly into your IDE. Ask your AI assistant to investigate a production error, and Steadwing returns the root cause with a suggested fix, no context switching or browser tabs required. Trigger full RCA on errors, alerts, or stack traces from your IDE Leverages your connected integrations for deeper insights Pass relevant source files for more accurate results Stay in your editor while Steadwing investigates ## Setup Get your API key from [app.steadwing.com/organization](https://app.steadwing.com/organization). ## Installation Add to your project's `.cursor/mcp.json`: ```json theme={null} { "mcpServers": { "steadwing": { "command": "npx", "args": ["-y", "@steadwing/mcp-server"], "env": { "STEADWING_API_KEY": "your_api_key_here" } } } } ``` Or install via the [Cursor Marketplace](https://cursor.com/plugins) (search "Steadwing"). ```bash theme={null} npx @smithery/cli install @steadwing/mcp-server --client claude ``` Or with pre-configured API key: ```bash theme={null} npx @smithery/cli install @steadwing/mcp-server --client claude --config '{"Steadwing API Key":"your_api_key_here"}' ``` Add to your Claude Desktop config: * macOS: `~/Library/Application Support/Claude/claude_desktop_config.json` * Windows: `%APPDATA%\Claude\claude_desktop_config.json` ```json theme={null} { "mcpServers": { "steadwing": { "command": "npx", "args": ["-y", "@steadwing/mcp-server"], "env": { "STEADWING_API_KEY": "your_api_key_here" } } } } ``` Restart Claude Desktop after updating config. This server uses stdio transport. Run it with: ```bash theme={null} STEADWING_API_KEY=your_key npx -y @steadwing/mcp-server ``` ## Tool: `run_rca` The MCP server exposes a single tool `run_rca` that analyzes errors with AI-powered root cause analysis. **Input:** | Parameter | Required | Description | | --------- | -------- | --------------------------------------------------------------- | | `error` | Yes | Error message, stack trace, or incident description | | `files` | No | Array of `{ name, content }` for relevant source files (max 20) | **Output:** A URL to the incident on Steadwing where you can view the full analysis. Including relevant source files is strongly recommended for more accurate analysis. Start with files mentioned in the stack trace, then add related imports and configuration files. ## How do I use the MCP server for debugging? ### Investigating a Production Error You're debugging an issue and have a stack trace. Instead of manually searching logs and code: ```text theme={null} "Hey, investigate this error: ConnectionTimeout in PaymentService.processOrder()" ``` Steadwing automatically: * Searches your connected observability tools for related errors * Correlates with recent code changes in GitHub * Identifies the likely root cause * Suggests a fix ### Analyzing Suspicious Code You're reviewing code and something looks off: ```text theme={null} "Investigate why this function might be causing memory leaks" ``` Steadwing examines the code pattern, checks for similar issues in your codebase, and explains potential problems with actionable recommendations. ### Understanding an Alert An alert fires and you want quick context: ```text theme={null} "What's causing the high latency alerts on the checkout service?" ``` Steadwing pulls metrics, recent deployments, and error patterns to give you a complete picture without leaving your editor. ## How do integrations enhance MCP server results? The MCP server works best when your Steadwing account has integrations connected: | Integration | What It Adds | | --------------------- | ------------------------------------------------------ | | **GitHub** | Repository context, recent commits, deployment history | | **Datadog / Grafana** | Metrics, monitors, and APM data | | **Sentry** | Error tracking and stack traces | | **AWS / GCP** | Cloud resource and service insights | Connect integrations at [app.steadwing.com/settings](https://app.steadwing.com/integrations) to unlock full investigation capabilities. ## FAQs Yes, authentication is required. The MCP server connects to your Steadwing account to access your organization's integrations and provide accurate analysis. Sign up at [app.steadwing.com](https://app.steadwing.com) if you don't have an account. You can trigger root cause analysis on errors, stack traces, or alerts. Pass relevant source files alongside the error for more accurate results. The MCP server requires authentication and works best with integrations. Without integrations, investigation capabilities are limited to local code analysis. Cursor and Claude Desktop have the best MCP support. Any MCP-compatible client will work, check [Smithery](https://smithery.ai/server/@steadwing/mcp) for the latest compatibility. Only relevant file snippets you explicitly pass (via the `files` parameter) are sent for analysis. Review our privacy policy at steadwing.com for details. Need help? Contact us at [hello@steadwing.com](mailto:hello@steadwing.com)