# Run Agent
Source: https://docs.incidentfox.ai/api-reference/agent/run
Trigger an investigation via the API
## Endpoint
```
POST /api/v1/agents/run
```
Triggers an investigation using the specified agent.
## Authentication
Requires Team Token or Admin Token.
## Request
### Headers
| Header | Required | Description |
| --------------- | -------- | ------------------- |
| `Authorization` | Yes | `Bearer YOUR_TOKEN` |
| `Content-Type` | Yes | `application/json` |
### Body Parameters
| Parameter | Type | Required | Description |
| ------------ | ------- | -------- | ----------------------------------- |
| `agent_name` | string | Yes | Agent to invoke |
| `message` | string | Yes | Investigation request |
| `context` | object | No | Additional context |
| `async` | boolean | No | Return immediately (default: false) |
### Available Agents
| Agent | Description |
| --------------------- | -------------------------------- |
| `planner` | Orchestrates full investigations |
| `investigation_agent` | Comprehensive troubleshooting |
| `k8s_agent` | Kubernetes-focused |
| `aws_agent` | AWS-focused |
| `coding_agent` | Code analysis |
## Request Example
```bash theme={null}
curl -X POST https://api.incidentfox.ai/api/v1/agents/run \
-H "Authorization: Bearer $TEAM_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"agent_name": "planner",
"message": "Investigate high latency in the payments service",
"context": {
"service": "payments",
"environment": "production",
"severity": "high"
}
}'
```
## Response
### Success Response (200)
```json theme={null}
{
"investigation_id": "inv_abc123",
"status": "completed",
"duration_seconds": 45,
"result": {
"summary": "Payment service experiencing elevated latency due to database connection pool exhaustion",
"root_cause": {
"description": "RDS connection pool at maximum capacity (100/100 connections)",
"confidence": 92,
"evidence": [
"CloudWatch RDS connections metric at 100%",
"Application logs show 'connection timeout' errors",
"Spike correlates with deployment at 14:32 UTC"
]
},
"timeline": [
{
"timestamp": "2024-01-15T14:32:00Z",
"event": "New deployment rolled out"
},
{
"timestamp": "2024-01-15T14:35:00Z",
"event": "Connection count started increasing"
},
{
"timestamp": "2024-01-15T14:42:00Z",
"event": "Connection pool exhausted"
}
],
"affected_systems": [
"payments-service",
"checkout-service",
"RDS primary"
],
"recommendations": [
{
"priority": "high",
"action": "Increase RDS max_connections parameter"
},
{
"priority": "medium",
"action": "Review connection pool settings in application config"
},
{
"priority": "low",
"action": "Consider connection pooler like PgBouncer"
}
]
},
"tools_used": [
"get_cloudwatch_logs",
"get_cloudwatch_metrics",
"get_pod_logs",
"search_github_code"
],
"created_at": "2024-01-15T14:45:00Z"
}
```
### Async Response (202)
When `async: true`:
```json theme={null}
{
"investigation_id": "inv_abc123",
"status": "running",
"poll_url": "/api/v1/agents/status/inv_abc123",
"created_at": "2024-01-15T14:45:00Z"
}
```
### Error Responses
**400 Bad Request**
```json theme={null}
{
"error": {
"code": "invalid_request",
"message": "agent_name is required"
}
}
```
**401 Unauthorized**
```json theme={null}
{
"error": {
"code": "unauthorized",
"message": "Invalid or expired token"
}
}
```
**429 Rate Limited**
```json theme={null}
{
"error": {
"code": "rate_limited",
"message": "Too many investigation requests",
"retry_after": 60
}
}
```
## Async Investigations
For long-running investigations, use async mode:
```bash theme={null}
curl -X POST https://api.incidentfox.ai/api/v1/agents/run \
-H "Authorization: Bearer $TEAM_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"agent_name": "planner",
"message": "Full system health check",
"async": true
}'
```
Then poll for results:
```bash theme={null}
curl -X GET https://api.incidentfox.ai/api/v1/agents/status/inv_abc123 \
-H "Authorization: Bearer $TEAM_TOKEN"
```
## Context Parameters
Provide additional context to improve investigation accuracy:
```json theme={null}
{
"context": {
"service": "payments",
"environment": "production",
"namespace": "checkout",
"severity": "high",
"related_alert": "alert_xyz789",
"time_window": "1h",
"hint": "Check recent deployments"
}
}
```
| Context Field | Description |
| --------------- | ------------------------ |
| `service` | Target service name |
| `environment` | prod, staging, dev |
| `namespace` | Kubernetes namespace |
| `severity` | high, medium, low |
| `related_alert` | Alert ID for context |
| `time_window` | Investigation time range |
| `hint` | Additional guidance |
## Code Examples
### Python
```python theme={null}
import requests
response = requests.post(
"https://api.incidentfox.ai/api/v1/agents/run",
headers={
"Authorization": f"Bearer {TEAM_TOKEN}",
"Content-Type": "application/json"
},
json={
"agent_name": "planner",
"message": "Investigate high latency in payments"
}
)
result = response.json()
print(f"Root cause: {result['result']['root_cause']['description']}")
```
### JavaScript
```javascript theme={null}
const response = await fetch('https://api.incidentfox.ai/api/v1/agents/run', {
method: 'POST',
headers: {
'Authorization': `Bearer ${TEAM_TOKEN}`,
'Content-Type': 'application/json'
},
body: JSON.stringify({
agent_name: 'planner',
message: 'Investigate high latency in payments'
})
});
const result = await response.json();
console.log(`Root cause: ${result.result.root_cause.description}`);
```
## Next Steps
Poll investigation status
Get team configuration
# Investigation Status
Source: https://docs.incidentfox.ai/api-reference/agent/status
Check the status of an investigation
## Endpoint
```
GET /api/v1/agents/status/{investigation_id}
```
Get the status and results of an investigation.
## Authentication
Requires Team Token or Admin Token.
## Path Parameters
| Parameter | Type | Required | Description |
| ------------------ | ------ | -------- | ---------------- |
| `investigation_id` | string | Yes | Investigation ID |
## Request Example
```bash theme={null}
curl -X GET https://api.incidentfox.ai/api/v1/agents/status/inv_abc123 \
-H "Authorization: Bearer $TEAM_TOKEN"
```
## Response
### Running Investigation
```json theme={null}
{
"investigation_id": "inv_abc123",
"status": "running",
"agent": "planner",
"message": "Investigate high latency in payments",
"progress": {
"current_step": "Querying CloudWatch metrics",
"steps_completed": 3,
"steps_total": 7
},
"started_at": "2024-01-15T14:45:00Z",
"elapsed_seconds": 15
}
```
### Completed Investigation
```json theme={null}
{
"investigation_id": "inv_abc123",
"status": "completed",
"agent": "planner",
"message": "Investigate high latency in payments",
"result": {
"summary": "Root cause identified as database connection pool exhaustion",
"root_cause": { ... },
"recommendations": [ ... ]
},
"tools_used": ["get_cloudwatch_logs", "get_pod_logs"],
"started_at": "2024-01-15T14:45:00Z",
"completed_at": "2024-01-15T14:45:45Z",
"duration_seconds": 45
}
```
### Failed Investigation
```json theme={null}
{
"investigation_id": "inv_abc123",
"status": "failed",
"agent": "planner",
"message": "Investigate high latency in payments",
"error": {
"code": "data_source_unavailable",
"message": "Unable to connect to Coralogix"
},
"started_at": "2024-01-15T14:45:00Z",
"failed_at": "2024-01-15T14:45:30Z"
}
```
## Status Values
| Status | Description |
| ----------- | ------------------------- |
| `pending` | Queued, not yet started |
| `running` | Investigation in progress |
| `completed` | Successfully completed |
| `failed` | Investigation failed |
| `cancelled` | Cancelled by user |
## Polling Strategy
For async investigations, poll with exponential backoff:
```python theme={null}
import time
import requests
def wait_for_investigation(investigation_id, token, max_wait=300):
url = f"https://api.incidentfox.ai/api/v1/agents/status/{investigation_id}"
headers = {"Authorization": f"Bearer {token}"}
wait_time = 1
total_wait = 0
while total_wait < max_wait:
response = requests.get(url, headers=headers)
result = response.json()
if result["status"] in ["completed", "failed", "cancelled"]:
return result
time.sleep(wait_time)
total_wait += wait_time
wait_time = min(wait_time * 2, 10) # Max 10 second intervals
raise TimeoutError("Investigation did not complete in time")
```
## List Recent Investigations
```
GET /api/v1/agents/investigations
```
List recent investigations for your team:
```bash theme={null}
curl -X GET "https://api.incidentfox.ai/api/v1/agents/investigations?limit=10" \
-H "Authorization: Bearer $TEAM_TOKEN"
```
Response:
```json theme={null}
{
"investigations": [
{
"investigation_id": "inv_abc123",
"status": "completed",
"agent": "planner",
"message": "Investigate high latency...",
"created_at": "2024-01-15T14:45:00Z"
},
{
"investigation_id": "inv_def456",
"status": "completed",
"agent": "k8s_agent",
"message": "Check pod status...",
"created_at": "2024-01-15T13:30:00Z"
}
],
"pagination": {
"total": 42,
"limit": 10,
"offset": 0
}
}
```
## Cancel Investigation
```
POST /api/v1/agents/status/{investigation_id}/cancel
```
Cancel a running investigation:
```bash theme={null}
curl -X POST https://api.incidentfox.ai/api/v1/agents/status/inv_abc123/cancel \
-H "Authorization: Bearer $TEAM_TOKEN"
```
## Next Steps
Trigger new investigation
Get team configuration
# Authentication
Source: https://docs.incidentfox.ai/api-reference/authentication
Authenticate with the IncidentFox API
## Overview
IncidentFox supports multiple authentication methods:
* **Team Tokens** - For programmatic team access
* **Admin Tokens** - For organization administration
* **OIDC/SSO** - For user authentication via identity provider
## Team Tokens
Team tokens provide access scoped to a specific team within an organization.
### Token Format
```
tokid.toksecret
```
* `tokid` - Token identifier (public)
* `toksecret` - Token secret (keep secure)
### Usage
Include in the `Authorization` header:
```bash theme={null}
curl -X GET https://api.incidentfox.ai/api/v1/config/me/effective \
-H "Authorization: Bearer tokid.toksecret"
```
### Obtaining Tokens
Team tokens are issued by your organization admin:
1. Admin logs into Web UI
2. Navigates to **Admin Console** > **Teams**
3. Selects team and clicks **Generate Token**
4. Token is displayed once - save it securely
### Token Permissions
Team tokens can:
* Read team configuration
* Update team configuration
* Trigger investigations
* View investigation history
Team tokens cannot:
* Access other teams
* Modify organization settings
* Create/delete teams
## Admin Tokens
Admin tokens provide organization-wide access.
### Permissions
Admin tokens can:
* Manage all teams
* View audit logs
* Configure organization settings
* Create/revoke team tokens
### Usage
```bash theme={null}
curl -X GET https://api.incidentfox.ai/api/v1/admin/teams \
-H "Authorization: Bearer admin.tokensecret"
```
## OIDC/SSO Authentication
For user-based authentication via your identity provider.
### Configuration
Configure OIDC in organization settings:
```json theme={null}
{
"oidc": {
"issuer": "https://login.company.com",
"client_id": "incidentfox-app",
"client_secret": "vault://secrets/oidc-secret"
}
}
```
### Supported Providers
* Google Workspace
* Azure AD
* Okta
* Auth0
* Generic OIDC
### JWT Token Usage
After OIDC authentication, use the JWT:
```bash theme={null}
curl -X GET https://api.incidentfox.ai/api/v1/config/me/effective \
-H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
```
## Identifying the Caller
Use the `/auth/me` endpoint to identify the authenticated user/team:
```bash theme={null}
curl -X GET https://api.incidentfox.ai/api/v1/auth/me \
-H "Authorization: Bearer YOUR_TOKEN"
```
Response:
```json theme={null}
{
"role": "team",
"auth_kind": "team_token",
"org_id": "org-acme",
"team_node_id": "team-platform",
"subject": null,
"email": null,
"can_write": true,
"permissions": ["team:read", "team:write"]
}
```
For OIDC users:
```json theme={null}
{
"role": "user",
"auth_kind": "oidc_jwt",
"org_id": "org-acme",
"team_node_id": null,
"subject": "user@company.com",
"email": "user@company.com",
"can_write": true,
"permissions": ["admin:read", "admin:write"]
}
```
## Token Security
Treat tokens like passwords. Never commit to version control or share publicly.
### Best Practices
1. **Store securely** - Use secrets managers
2. **Rotate regularly** - Rotate tokens periodically
3. **Use least privilege** - Use team tokens when admin isn't needed
4. **Monitor usage** - Review audit logs for anomalies
5. **Revoke unused** - Revoke tokens when no longer needed
### Token Revocation
Admins can revoke tokens:
```bash theme={null}
curl -X POST https://api.incidentfox.ai/api/v1/admin/tokens/revoke \
-H "Authorization: Bearer admin.token" \
-H "Content-Type: application/json" \
-d '{"token_id": "tokid"}'
```
## Error Handling
### Invalid Token
```json theme={null}
{
"error": {
"code": "unauthorized",
"message": "Invalid or expired token"
}
}
```
### Expired Token
```json theme={null}
{
"error": {
"code": "token_expired",
"message": "Token has expired"
}
}
```
### Insufficient Permissions
```json theme={null}
{
"error": {
"code": "forbidden",
"message": "Token does not have permission for this operation"
}
}
```
## Next Steps
Trigger investigations
Read team configuration
# Get Effective Config
Source: https://docs.incidentfox.ai/api-reference/config/effective
Retrieve your team's effective configuration
## Endpoint
```
GET /api/v1/config/me/effective
```
Returns the fully merged configuration for the authenticated team, including all inherited settings from organization and group levels.
## Authentication
Requires Team Token or Admin Token.
## Request Example
```bash theme={null}
curl -X GET https://api.incidentfox.ai/api/v1/config/me/effective \
-H "Authorization: Bearer $TEAM_TOKEN"
```
## Response
### Success Response (200)
```json theme={null}
{
"team_name": "platform-devops",
"tokens_vault_path": {
"openai_token": "vault://org/acme/teams/platform-devops/openai",
"slack_bot": "vault://org/acme/teams/platform-devops/slack-bot"
},
"mcp_servers": ["grafana", "aws", "coralogix"],
"a2a_agents": ["investigation", "code_fix"],
"slack_group_to_ping": "@platform-oncall",
"slack_channel": "#incidents-platform",
"knowledge_source": {
"grafana": ["dash/123", "dash/456"],
"google": ["drive:folder/abc"],
"confluence": ["space:PLAT:runbooks"]
},
"agents": {
"investigation_agent": {
"prompt": "You are an SRE investigation agent for Acme Corp...",
"enabled": true,
"disable_default_tools": [],
"enable_extra_tools": ["coralogix", "snowflake"]
},
"code_fix_agent": {
"prompt": "Provide minimal, safe hotfix suggestions",
"enabled": true,
"disable_default_tools": ["db-write"],
"enable_extra_tools": ["repo-read"]
}
},
"feature_flags": {
"enable_auto_mitigation": false,
"enable_write_actions": true,
"require_approval": true
},
"alerts": {
"disabled": ["cpu_throttle_high", "disk_pressure"]
},
"tools": {
"kubernetes": {
"enabled": true,
"default_namespace": "production"
},
"coralogix": {
"enabled": true,
"domain": "coralogix.com"
}
}
}
```
## Understanding Effective Config
The effective config is computed by merging configs from:
1. **Organization defaults** (root level)
2. **Group configs** (intermediate levels)
3. **Team config** (leaf level)
Later levels override earlier levels via deep merge.
## Get Raw Config with Lineage
To understand where settings come from:
```
GET /api/v1/config/me/raw
```
```bash theme={null}
curl -X GET https://api.incidentfox.ai/api/v1/config/me/raw \
-H "Authorization: Bearer $TEAM_TOKEN"
```
Response:
```json theme={null}
{
"lineage": [
"org-acme",
"engineering-group",
"platform-team"
],
"configs": {
"org-acme": {
"mcp_servers": ["grafana", "aws"],
"feature_flags": {
"enable_auto_mitigation": false
}
},
"engineering-group": {
"slack_channel": "#engineering-incidents"
},
"platform-team": {
"mcp_servers": ["grafana", "aws", "coralogix"],
"slack_channel": "#incidents-platform",
"agents": {
"investigation_agent": {
"enable_extra_tools": ["coralogix", "snowflake"]
}
}
}
}
}
```
## Get Config Audit History
View configuration change history:
```
GET /api/v1/config/me/audit
```
```bash theme={null}
curl -X GET "https://api.incidentfox.ai/api/v1/config/me/audit?limit=10" \
-H "Authorization: Bearer $TEAM_TOKEN"
```
Response:
```json theme={null}
{
"history": [
{
"version": 5,
"changed_at": "2024-01-15T10:30:00Z",
"changed_by": "user@company.com",
"diff": {
"mcp_servers": {
"old": ["grafana", "aws"],
"new": ["grafana", "aws", "coralogix"]
}
},
"full_config": { ... }
},
{
"version": 4,
"changed_at": "2024-01-10T08:00:00Z",
"changed_by": "admin@company.com",
"diff": {
"agents.investigation_agent.prompt": {
"old": "You are an investigation agent...",
"new": "You are an SRE investigation agent..."
}
}
}
]
}
```
### Query Parameters
| Parameter | Type | Default | Description |
| -------------- | ---- | ------- | ---------------------------- |
| `limit` | int | 50 | Number of entries |
| `include_full` | bool | true | Include full config snapshot |
## Code Examples
### Python
```python theme={null}
import requests
def get_team_config(token):
response = requests.get(
"https://api.incidentfox.ai/api/v1/config/me/effective",
headers={"Authorization": f"Bearer {token}"}
)
response.raise_for_status()
return response.json()
config = get_team_config(TEAM_TOKEN)
print(f"MCP Servers: {config['mcp_servers']}")
print(f"Slack Channel: {config['slack_channel']}")
```
### JavaScript
```javascript theme={null}
async function getTeamConfig(token) {
const response = await fetch(
'https://api.incidentfox.ai/api/v1/config/me/effective',
{
headers: { 'Authorization': `Bearer ${token}` }
}
);
return response.json();
}
const config = await getTeamConfig(TEAM_TOKEN);
console.log('MCP Servers:', config.mcp_servers);
```
## Next Steps
Update team configuration
Trigger investigations
# Update Config
Source: https://docs.incidentfox.ai/api-reference/config/update
Update your team's configuration
## Endpoint
```
PUT /api/v1/config/me
```
Update the team's configuration overrides. Uses PATCH semantics - provided values are deep-merged with existing config.
## Authentication
Requires Team Token with write permissions.
## Request
### Headers
| Header | Required | Description |
| --------------- | -------- | ------------------- |
| `Authorization` | Yes | `Bearer YOUR_TOKEN` |
| `Content-Type` | Yes | `application/json` |
### Body
Partial configuration object. Only include fields you want to change.
## Request Example
```bash theme={null}
curl -X PUT https://api.incidentfox.ai/api/v1/config/me \
-H "Authorization: Bearer $TEAM_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"mcp_servers": ["grafana", "aws", "coralogix", "snowflake"],
"agents": {
"investigation_agent": {
"enable_extra_tools": ["snowflake", "custom-runbooks"]
}
}
}'
```
## Response
### Success Response (200)
```json theme={null}
{
"message": "Configuration updated successfully",
"version": 6,
"changed_fields": [
"mcp_servers",
"agents.investigation_agent.enable_extra_tools"
],
"effective_config": {
"mcp_servers": ["grafana", "aws", "coralogix", "snowflake"],
"agents": {
"investigation_agent": {
"prompt": "You are an SRE investigation agent...",
"enable_extra_tools": ["snowflake", "custom-runbooks"]
}
}
}
}
```
### Approval Required Response (202)
When approval workflows are enabled:
```json theme={null}
{
"message": "Configuration change submitted for approval",
"change_request_id": "cr_xyz789",
"status": "pending_approval",
"approvers": ["admin@company.com"],
"changes": {
"mcp_servers": {
"old": ["grafana", "aws", "coralogix"],
"new": ["grafana", "aws", "coralogix", "snowflake"]
}
}
}
```
### Error Responses
**400 Bad Request - Invalid Field**
```json theme={null}
{
"error": {
"code": "invalid_field",
"message": "team_name is immutable and cannot be changed",
"field": "team_name"
}
}
```
**400 Bad Request - Validation Error**
```json theme={null}
{
"error": {
"code": "validation_error",
"message": "Invalid configuration value",
"details": {
"field": "agents.investigation_agent.timeout",
"error": "must be a positive integer"
}
}
}
```
**403 Forbidden**
```json theme={null}
{
"error": {
"code": "forbidden",
"message": "Token does not have write permissions"
}
}
```
## Immutable Fields
These fields cannot be changed via API:
* `team_name` - Set by admin only
* `org_id` - Fixed at team creation
* `team_node_id` - Fixed at team creation
## Common Updates
### Add MCP Server
```json theme={null}
{
"mcp_servers": ["grafana", "aws", "coralogix", "new-server"]
}
```
### Update Agent Prompt
```json theme={null}
{
"agents": {
"investigation_agent": {
"prompt": "You are an SRE investigation agent for Acme Corp. Focus on database and payment issues first..."
}
}
}
```
### Enable Additional Tools
```json theme={null}
{
"agents": {
"investigation_agent": {
"enable_extra_tools": ["snowflake", "custom-tool"]
}
}
}
```
### Disable Dangerous Tools
```json theme={null}
{
"agents": {
"investigation_agent": {
"disable_default_tools": ["shell", "docker_exec"]
}
}
}
```
### Update Slack Settings
```json theme={null}
{
"slack_channel": "#new-incidents-channel",
"slack_group_to_ping": "@new-oncall-group"
}
```
### Enable Feature Flags
```json theme={null}
{
"feature_flags": {
"enable_auto_mitigation": true,
"require_approval": false
}
}
```
## Code Examples
### Python
```python theme={null}
import requests
def update_config(token, config_updates):
response = requests.put(
"https://api.incidentfox.ai/api/v1/config/me",
headers={
"Authorization": f"Bearer {token}",
"Content-Type": "application/json"
},
json=config_updates
)
response.raise_for_status()
return response.json()
# Add a new MCP server
result = update_config(TEAM_TOKEN, {
"mcp_servers": ["grafana", "aws", "coralogix", "snowflake"]
})
print(f"Config version: {result['version']}")
```
### JavaScript
```javascript theme={null}
async function updateConfig(token, updates) {
const response = await fetch(
'https://api.incidentfox.ai/api/v1/config/me',
{
method: 'PUT',
headers: {
'Authorization': `Bearer ${token}`,
'Content-Type': 'application/json'
},
body: JSON.stringify(updates)
}
);
return response.json();
}
const result = await updateConfig(TEAM_TOKEN, {
agents: {
investigation_agent: {
enable_extra_tools: ['snowflake']
}
}
});
```
## Validation
Before saving, the API validates:
1. **Schema compliance** - Fields match expected types
2. **Immutable fields** - Cannot change protected fields
3. **Tool existence** - Enabled tools must exist
4. **MCP server validity** - MCP servers must be configured
## Approval Workflows
If your organization has approval workflows enabled:
1. Updates create a pending change request
2. Admins are notified
3. Once approved, config is applied
4. Requester is notified
Check pending changes:
```
GET /api/v1/config/me/pending
```
## Next Steps
View current configuration
Configuration documentation
# API Introduction
Source: https://docs.incidentfox.ai/api-reference/introduction
Overview of the IncidentFox REST API
## Overview
The IncidentFox API provides programmatic access to:
* Trigger investigations
* Manage team configuration
* Query investigation history
* Integrate with custom workflows
## Base URL
```
https://api.incidentfox.ai/api/v1
```
## Authentication
All API endpoints require authentication via Bearer token.
```bash theme={null}
curl -X GET https://api.incidentfox.ai/api/v1/config/me/effective \
-H "Authorization: Bearer YOUR_TEAM_TOKEN"
```
### Token Types
| Type | Format | Scope |
| ----------- | ------------------- | ----------------------- |
| Team Token | `tokid.toksecret` | Team operations |
| Admin Token | `admin.tokensecret` | Organization admin |
| OIDC JWT | Standard JWT | SSO authenticated users |
Team tokens are issued by your organization admin. Contact them if you need API access.
## Response Format
All responses are JSON:
```json theme={null}
{
"data": { ... },
"meta": {
"request_id": "req_abc123",
"timestamp": "2024-01-15T10:30:00Z"
}
}
```
### Error Responses
```json theme={null}
{
"error": {
"code": "unauthorized",
"message": "Invalid or expired token",
"request_id": "req_abc123"
}
}
```
### HTTP Status Codes
| Code | Description |
| ---- | ------------ |
| 200 | Success |
| 400 | Bad request |
| 401 | Unauthorized |
| 403 | Forbidden |
| 404 | Not found |
| 429 | Rate limited |
| 500 | Server error |
## Rate Limiting
API requests are rate limited:
| Endpoint Type | Limit |
| ---------------------- | ---------- |
| Read operations | 100/minute |
| Write operations | 20/minute |
| Investigation triggers | 10/minute |
Rate limit headers are included in responses:
```
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 95
X-RateLimit-Reset: 1705318260
```
## API Categories
Trigger and manage investigations
Manage team configuration
## Quick Start
### Trigger an Investigation
```bash theme={null}
curl -X POST https://api.incidentfox.ai/api/v1/agents/run \
-H "Authorization: Bearer $TEAM_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"agent_name": "planner",
"message": "Investigate high latency in payments service"
}'
```
### Get Team Configuration
```bash theme={null}
curl -X GET https://api.incidentfox.ai/api/v1/config/me/effective \
-H "Authorization: Bearer $TEAM_TOKEN"
```
## SDKs
Official SDKs are available:
* **Python**: `pip install incidentfox`
* **JavaScript**: `npm install @incidentfox/sdk`
### Python Example
```python theme={null}
from incidentfox import IncidentFoxClient
client = IncidentFoxClient(token="YOUR_TEAM_TOKEN")
# Trigger investigation
result = client.investigate("High error rate in checkout service")
print(result.summary)
print(result.root_cause)
# Get team config
config = client.config.get_effective()
print(config.mcp_servers)
```
## Webhooks
Configure webhooks to receive investigation results:
```json theme={null}
{
"webhooks": {
"investigation_complete": "https://your-app.com/webhooks/incidentfox"
}
}
```
Webhook payload:
```json theme={null}
{
"event": "investigation_complete",
"investigation_id": "inv_abc123",
"summary": "Root cause identified",
"root_cause": { ... },
"recommendations": [ ... ]
}
```
## Next Steps
Detailed auth guide
Trigger investigations
# Agent Configuration
Source: https://docs.incidentfox.ai/configuration/agents
Configure agent behavior, prompts, and tool access
## Overview
IncidentFox agents can be customized through configuration to:
* Modify system prompts
* Enable or disable specific tools
* Add custom context about your infrastructure
* Tune behavior for your team's needs
## Agent Types
| Agent | Purpose | Default Tools |
| --------------------- | --------------------------- | ----------------------------- |
| `planner` | Orchestrate investigations | None (delegates to others) |
| `k8s_agent` | Kubernetes troubleshooting | 9 K8s-specific tools |
| `aws_agent` | AWS resource debugging | 8 AWS-specific tools |
| `metrics_agent` | Anomaly detection | 22 metrics/analytics tools |
| `coding_agent` | Code analysis | 15 code/git tools |
| `investigation_agent` | Full toolkit investigations | 30+ tools from all categories |
## Configuration Structure
Each agent is configured under the `agents` key:
```json theme={null}
{
"agents": {
"investigation_agent": {
"prompt": "System prompt for the agent...",
"enabled": true,
"disable_default_tools": ["shell", "docker_exec"],
"enable_extra_tools": ["custom-runbook-search"]
},
"code_fix_agent": {
"enabled": false
}
}
}
```
## Configuration Options
### `prompt`
The system prompt that defines the agent's behavior, knowledge, and communication style.
```json theme={null}
{
"agents": {
"investigation_agent": {
"prompt": "You are an AI SRE agent for Acme Corp. Our infrastructure runs on AWS EKS in us-west-2. Key services include: payments (critical), cart (high), catalog (medium). Always check CloudWatch metrics first, then pod logs. Escalate P1 incidents immediately to #incidents-critical."
}
}
}
```
**Include context about your infrastructure** in the prompt:
* Service criticality tiers
* Common failure patterns
* Escalation procedures
* Team-specific runbooks to reference
### `enabled`
Toggle an agent on or off. Defaults to `true`.
```json theme={null}
{
"agents": {
"code_fix_agent": {
"enabled": false
}
}
}
```
### `disable_default_tools`
Remove specific tools from an agent's default toolkit. Useful for security or compliance.
```json theme={null}
{
"agents": {
"investigation_agent": {
"disable_default_tools": [
"shell",
"docker_exec",
"db_write"
]
}
}
}
```
Disabling critical tools may impact investigation effectiveness. Test thoroughly before disabling in production.
### `enable_extra_tools`
Add tools beyond the agent's default set.
```json theme={null}
{
"agents": {
"investigation_agent": {
"enable_extra_tools": [
"coralogix",
"snowflake",
"custom-runbooks"
]
}
}
}
```
## Writing Effective Prompts
### Structure
A well-structured agent prompt includes:
1. **Role definition** - What the agent is and does
2. **Context** - Information about your infrastructure
3. **Guidelines** - How to approach investigations
4. **Constraints** - What to avoid or be careful about
5. **Output format** - How to structure responses
### Example: Investigation Agent
```
You are an AI SRE agent for Acme Corp's platform team.
## Infrastructure Context
- Cloud: AWS (us-west-2, us-east-1)
- Orchestration: EKS (Kubernetes 1.28)
- Key Services:
- payments-service (P0 - business critical)
- cart-service (P1 - customer facing)
- catalog-service (P2 - internal)
- analytics-service (P3 - batch processing)
## Observability Stack
- Logs: Coralogix (primary), CloudWatch (backup)
- Metrics: Grafana Cloud + Prometheus
- Traces: Datadog APM
- Alerts: PagerDuty -> Slack #incidents
## Investigation Guidelines
1. Always start by identifying affected services and their criticality
2. Check recent deployments (last 4 hours) first
3. Query Coralogix for error logs before CloudWatch
4. For database issues, check RDS Performance Insights
5. Correlate with recent PRs merged to main
## Response Format
Always include:
- Summary (1-2 sentences)
- Root cause with confidence level
- Evidence (specific logs, metrics, or events)
- Timeline of events
- Recommended actions with priority
## Constraints
- Never execute remediation without approval
- Escalate P0/P1 incidents immediately
- Don't access production databases directly
```
### Example: Slack Bot Agent
```
You are the IncidentFox Slack bot for Acme Corp.
## Communication Style
- Be concise and actionable
- Use bullet points for multiple items
- Include confidence levels when uncertain
- Link to dashboards and runbooks when relevant
## Quick Commands
When users say:
- "check [service]" -> Run health check on service
- "logs [service]" -> Fetch recent error logs
- "who's oncall" -> Check PagerDuty schedule
- "deploy status" -> Check recent deployments
## Escalation
For P0/P1, immediately ping @oncall-platform and post to #incidents-critical.
```
## Agent Specialization
### Creating Workflow-Specific Agents
You can create specialized agents for different workflows:
**CI/CD Investigation Agent:**
```json theme={null}
{
"agents": {
"ci_investigation_agent": {
"prompt": "You specialize in CI/CD failures. Focus on: build logs, test output, dependency changes, environment differences between PR and main.",
"enable_extra_tools": ["github_actions", "codepipeline", "ecr"]
}
}
}
```
**Database Investigation Agent:**
```json theme={null}
{
"agents": {
"db_investigation_agent": {
"prompt": "You specialize in database performance issues. Check RDS metrics, slow query logs, connection pools, and recent schema changes.",
"enable_extra_tools": ["rds_insights", "pg_stat_statements", "snowflake"]
}
}
}
```
## Tuning Tips
### Improve Root Cause Accuracy
1. **Add service dependencies** to the prompt
2. **Include common failure patterns** you've seen
3. **Specify data source priority** (which to check first)
4. **Add context about recent changes** (migrations, refactors)
### Reduce Investigation Time
1. **Prioritize fast data sources** in the prompt
2. **Include known quick wins** (common issues and solutions)
3. **Set appropriate timeouts** for tool execution
### Improve Response Quality
1. **Define output format** explicitly
2. **Include examples** of good responses
3. **Specify confidence thresholds** for recommendations
## Validation
Before deploying prompt changes:
1. **Test in staging** with known scenarios
2. **Compare results** with previous prompt version
3. **Check for regressions** in accuracy or speed
If approval workflows are enabled, prompt changes require admin approval before taking effect.
## Next Steps
Configure and customize tools
Advanced prompt engineering
# Configuration Overview
Source: https://docs.incidentfox.ai/configuration/overview
Understanding IncidentFox configuration hierarchy and options
## Configuration Model
IncidentFox uses a hierarchical configuration system that allows organizations to set defaults while enabling teams to customize their specific needs.
### Hierarchy
```mermaid theme={null}
graph TD
A[Organization root]
A --> B[Engineering Group]
A --> C[Infrastructure Group]
B --> D[Platform Team]
B --> E[Backend Team]
C --> F[SRE Team]
C --> G[DevOps Team]
```
Configuration flows from top to bottom. Each level can:
* **Inherit** settings from parent levels
* **Override** specific settings
* **Add** additional configuration
### How Merging Works
When IncidentFox loads a team's configuration, it:
1. Starts with organization defaults
2. Deep-merges each intermediate group's config
3. Deep-merges the team's config
4. Returns the final "effective config"
Deep merge means nested objects are merged recursively, not replaced entirely. Arrays are typically replaced, not concatenated.
### Example
**Organization Config:**
```json theme={null}
{
"mcp_servers": ["grafana", "aws"],
"agents": {
"investigation_agent": {
"prompt": "You are an SRE investigation agent for Acme Corp..."
}
},
"feature_flags": {
"enable_auto_mitigation": false
}
}
```
**Team Config (Platform Team):**
```json theme={null}
{
"mcp_servers": ["grafana", "aws", "coralogix"],
"agents": {
"investigation_agent": {
"enable_extra_tools": ["snowflake", "custom-runbooks"]
}
}
}
```
**Effective Config for Platform Team:**
```json theme={null}
{
"mcp_servers": ["grafana", "aws", "coralogix"],
"agents": {
"investigation_agent": {
"prompt": "You are an SRE investigation agent for Acme Corp...",
"enable_extra_tools": ["snowflake", "custom-runbooks"]
}
},
"feature_flags": {
"enable_auto_mitigation": false
}
}
```
## Configuration Sections
### Core Settings
| Field | Type | Description |
| --------------------- | ------ | ------------------------------------------- |
| `team_name` | string | Display name (immutable at team level) |
| `slack_channel` | string | Default Slack channel for notifications |
| `slack_group_to_ping` | string | Group to mention (e.g., `@oncall-platform`) |
### Agent Configuration
Configure behavior for each agent type:
```json theme={null}
{
"agents": {
"investigation_agent": {
"prompt": "Custom system prompt...",
"enabled": true,
"disable_default_tools": ["shell"],
"enable_extra_tools": ["custom-tool"]
}
}
}
```
See [Agent Configuration](/configuration/agents) for details.
### Tool Configuration
Enable/disable and configure tools:
```json theme={null}
{
"tools": {
"kubernetes": {
"enabled": true,
"default_namespace": "production"
},
"coralogix": {
"enabled": true,
"api_key": "vault://secrets/coralogix-api-key"
}
}
}
```
See [Tool Configuration](/configuration/tools) for details.
### MCP Servers
Configure Model Context Protocol servers:
```json theme={null}
{
"mcp_servers": ["grafana", "aws", "custom-server"]
}
```
### Knowledge Sources
Configure where agents look for documentation and runbooks:
```json theme={null}
{
"knowledge_source": {
"grafana": ["prod-k8s", "prod-logs"],
"google": ["drive:folder/oncall-runbooks"],
"confluence": ["space:SRE"]
}
}
```
### Feature Flags
Control feature behavior:
```json theme={null}
{
"feature_flags": {
"enable_auto_mitigation": false,
"enable_write_actions": true,
"require_approval": true
}
}
```
### Alerts Configuration
Customize alert handling:
```json theme={null}
{
"alerts": {
"disabled": ["cpu_throttle_high", "disk_pressure"]
}
}
```
## Managing Configuration
### Via Web UI
1. Log in to your IncidentFox dashboard
2. Navigate to **Team Console** > **Configuration**
3. Edit settings in the visual editor
4. Save changes (may require approval if enabled)
### Via API
```bash theme={null}
# Get effective config
curl -X GET https://api.incidentfox.ai/api/v1/config/me/effective \
-H "Authorization: Bearer $TEAM_TOKEN"
# Update team config
curl -X PUT https://api.incidentfox.ai/api/v1/config/me \
-H "Authorization: Bearer $TEAM_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"mcp_servers": ["grafana", "aws", "coralogix"]
}'
```
### Viewing Raw Lineage
To understand why a setting has a particular value:
```bash theme={null}
curl -X GET https://api.incidentfox.ai/api/v1/config/me/raw \
-H "Authorization: Bearer $TEAM_TOKEN"
```
Returns:
```json theme={null}
{
"lineage": ["org-root", "engineering-group", "platform-team"],
"configs": {
"org-root": { /* org config */ },
"engineering-group": { /* group config */ },
"platform-team": { /* team config */ }
}
}
```
## Audit Trail
All configuration changes are logged. View the audit history:
```bash theme={null}
curl -X GET https://api.incidentfox.ai/api/v1/config/me/audit \
-H "Authorization: Bearer $TEAM_TOKEN"
```
Returns:
```json theme={null}
[
{
"version": 5,
"changed_at": "2024-01-15T10:30:00Z",
"changed_by": "user@company.com",
"diff": {
"mcp_servers": {
"old": ["grafana", "aws"],
"new": ["grafana", "aws", "coralogix"]
}
}
}
]
```
## Best Practices
**Start broad, refine narrow** - Set sensible defaults at the org level, then let teams customize as needed.
1. **Use org-level defaults** for common settings
2. **Group by function** - Platform teams vs. application teams may need different configs
3. **Minimize team overrides** - Only override what's truly team-specific
4. **Use vault references** for secrets - Never store credentials in plain text
5. **Enable approval workflows** for production teams
## Next Steps
Configure agent behavior and prompts
Enable and configure tools
# System Prompts
Source: https://docs.incidentfox.ai/configuration/prompts
Advanced guide to writing effective agent prompts
## Overview
System prompts are the primary way to customize agent behavior. A well-crafted prompt can significantly improve investigation accuracy, response quality, and team alignment.
## Prompt Architecture
```mermaid theme={null}
graph TD
A[System Prompt] --> D[User Message
investigate high latency in payments]
D --> E[Agent Response
follows prompt guidelines]
B[1. Role & Identity
2. Context & Knowledge
3. Guidelines & Process
4. Constraints & Guardrails
5. Output Format] -.->|Components| A
```
## Section-by-Section Guide
### 1. Role & Identity
Define who the agent is and its primary purpose.
```
You are an AI SRE agent for Acme Corp's Platform Engineering team. Your primary responsibility is investigating production incidents and providing actionable insights to reduce MTTR.
```
**Include:**
* Organization name
* Team the agent serves
* Primary responsibility
### 2. Context & Knowledge
Provide infrastructure context the agent needs to know.
```
## Infrastructure Overview
**Cloud**: AWS (primary: us-west-2, DR: us-east-1)
**Orchestration**: EKS 1.28 with Karpenter autoscaling
**Service Mesh**: Istio 1.20
## Services
| Service | Criticality | Team | Notes |
|---------|-------------|------|-------|
| payments | P0 | checkout | PCI compliant, separate VPC |
| cart | P1 | checkout | Redis for session |
| catalog | P2 | inventory | Read-heavy, uses caching |
| analytics | P3 | data | Batch, can tolerate delays |
## Data Sources
- **Logs**: Coralogix (primary), CloudWatch (backup)
- **Metrics**: Grafana Cloud (Prometheus)
- **Traces**: Datadog APM
- **Alerts**: PagerDuty → Slack
- **Enrichment**: Snowflake (historical data)
## Key Dashboards
- Production Overview: https://grafana.acme.com/d/prod-overview
- Error Rates: https://grafana.acme.com/d/errors
- Database Performance: https://grafana.acme.com/d/rds
```
**Include:**
* Cloud and infrastructure details
* Service catalog with criticality
* Data source locations
* Important dashboards/runbooks
### 3. Guidelines & Process
Define how the agent should approach investigations.
```
## Investigation Process
1. **Identify scope**: Determine affected services and their criticality
2. **Recent changes first**: Check deployments in the last 4 hours
3. **Follow the data**:
- Coralogix for application logs
- CloudWatch for infrastructure logs
- Grafana for metrics correlation
- Snowflake for historical patterns
4. **Correlate**: Look for timing relationships between events
5. **Verify**: Confirm findings with multiple data sources
## Priority Rules
- P0 services: Escalate immediately, investigate in parallel
- P1 services: Investigate promptly, escalate if not resolved in 15min
- P2/P3 services: Normal investigation flow
## Common Patterns
1. **Deployment correlation**: 80% of incidents happen within 4 hours of deploy
2. **Database issues**: Check connection pools before blaming the DB
3. **Network issues**: Verify Istio sidecar health first
4. **Memory issues**: Look for memory leaks in pod restarts
```
**Include:**
* Step-by-step investigation process
* Priority/escalation rules
* Common patterns you've observed
* Preferred data source order
### 4. Constraints & Guardrails
Define what the agent should NOT do.
```
## Constraints
- **Never** execute remediation without explicit approval
- **Never** access production databases directly
- **Never** share PII or sensitive data in responses
- **Do not** restart services without oncall confirmation
- **Limit** CloudWatch queries to 24 hours to control costs
## Escalation Rules
Escalate immediately (do not investigate alone) when:
- Multiple P0 services affected
- Data integrity concerns (payments, user data)
- Security-related symptoms
- Customer-facing impact confirmed
## Sensitive Data
These fields are PII and should never be logged or displayed:
- user_email, customer_id, payment_token, ssn, credit_card
```
**Include:**
* Explicit prohibitions
* Escalation triggers
* Security/compliance requirements
* Cost control measures
### 5. Output Format
Define how responses should be structured.
```
## Response Format
Always structure responses as:
### Summary
[1-2 sentence overview of findings]
### Root Cause
- **Description**: [What went wrong]
- **Confidence**: [Low/Medium/High with percentage]
- **Evidence**: [Bulleted list of supporting data]
### Timeline
[Chronological list of relevant events]
### Affected Systems
[List of impacted services/components]
### Recommendations
[Numbered list of suggested actions, in priority order]
### Next Steps
[Immediate actions needed]
## Confidence Levels
- **High (80-100%)**: Multiple data sources confirm, clear causation
- **Medium (50-79%)**: Strong correlation, some ambiguity
- **Low (<50%)**: Limited data, hypothesis only
```
**Include:**
* Response structure
* Required sections
* Confidence level definitions
* Example formats
## Complete Example
```
You are an AI SRE agent for Acme Corp's Platform Engineering team.
## Infrastructure
**Cloud**: AWS (us-west-2)
**Orchestration**: EKS 1.28
**Services**: payments (P0), cart (P1), catalog (P2), analytics (P3)
## Data Sources
- Logs: Coralogix (primary)
- Metrics: Grafana Cloud
- Traces: Datadog
- Enrichment: Snowflake
## Investigation Process
1. Identify affected services and criticality
2. Check recent deployments (last 4 hours)
3. Query Coralogix for error patterns
4. Check Grafana for metric anomalies
5. Correlate with GitHub for recent changes
6. Use Snowflake for historical context
## Constraints
- Never execute remediation without approval
- Escalate P0 incidents immediately to #incidents-critical
- Do not access production databases directly
## Response Format
### Summary
[1-2 sentences]
### Root Cause
- Description: [what]
- Confidence: [%]
- Evidence: [list]
### Timeline
[events]
### Recommendations
[actions]
```
## Testing Prompts
Before deploying a new prompt:
Run investigations for incidents you've already resolved
Check if the new prompt produces better/worse results
Ensure guardrails are respected
Get feedback from SREs who will use it
## Prompt Templates
### Investigation Agent (Generic)
```
You are an AI SRE agent for [COMPANY].
## Infrastructure
[Add your infrastructure details]
## Data Sources
[Add your observability stack]
## Investigation Process
[Add your preferred investigation steps]
## Constraints
[Add your guardrails]
## Response Format
[Add your preferred output structure]
```
### CI/CD Agent
```
You are an AI agent specializing in CI/CD failures for [COMPANY].
## CI/CD Stack
- CI: [GitHub Actions/Jenkins/etc]
- CD: [CodePipeline/ArgoCD/etc]
- Registry: [ECR/Docker Hub/etc]
## Investigation Focus
1. Build failures: Check logs, dependencies, environment
2. Test failures: Analyze test output, compare with main
3. Deploy failures: Check permissions, resources, health checks
## Common Issues
[Add patterns you've seen]
```
## Next Steps
Apply prompts to agents
See available tools to reference in prompts
# Tool Configuration
Source: https://docs.incidentfox.ai/configuration/tools
Enable, configure, and customize IncidentFox tools
## Overview
IncidentFox provides 50+ built-in tools across multiple categories. Each tool can be:
* **Enabled/disabled** per team
* **Configured** with credentials and settings
* **Customized** with team-specific defaults
## Tool Categories
| Category | Tools | Description |
| ----------------- | ----- | --------------------------------------------- |
| Kubernetes | 9 | Pod logs, deployments, events, resource usage |
| AWS | 8 | EC2, Lambda, RDS, ECS, CloudWatch |
| Anomaly Detection | 8 | Prophet forecasting, Z-score, correlation |
| Grafana | 6 | Dashboards, Prometheus queries, alerts |
| Datadog | 3 | Metrics, logs, APM |
| New Relic | 2 | NRQL queries, APM summary |
| Coralogix | 4 | Log search, alerts, metrics |
| Snowflake | 3 | SQL queries, data enrichment |
| GitHub | 16 | Code search, PRs, issues, workflows |
| Git | 12 | Status, diff, log, blame |
| Docker | 15 | Build, run, logs, exec |
| Elasticsearch | 3 | Log search, aggregations |
| Slack | 5 | Messages, channels, threads |
## Configuration Structure
Tools are configured under the `tools` key:
```json theme={null}
{
"tools": {
"kubernetes": {
"enabled": true,
"default_namespace": "production",
"kubeconfig_path": "/path/to/kubeconfig"
},
"coralogix": {
"enabled": true,
"api_key": "vault://secrets/coralogix-api-key",
"domain": "coralogix.com"
},
"snowflake": {
"enabled": true,
"account": "acme.us-west-2",
"warehouse": "COMPUTE_WH",
"credentials": "vault://secrets/snowflake"
}
}
}
```
## Common Configuration Options
### All Tools
| Option | Type | Description |
| --------- | ------- | ----------------------------- |
| `enabled` | boolean | Enable/disable the tool |
| `timeout` | integer | Max execution time in seconds |
### Credentials
Always use vault references for secrets:
```json theme={null}
{
"api_key": "vault://path/to/secret",
"password": "vault://path/to/password"
}
```
Never store credentials in plain text. Always use vault references.
## Tool-Specific Configuration
### Kubernetes
```json theme={null}
{
"tools": {
"kubernetes": {
"enabled": true,
"kubeconfig_path": "~/.kube/config",
"default_namespace": "production",
"default_context": "prod-cluster",
"timeout": 30
}
}
}
```
| Option | Default | Description |
| ------------------- | ---------------- | ----------------------------- |
| `kubeconfig_path` | `~/.kube/config` | Path to kubeconfig file |
| `default_namespace` | `default` | Default namespace for queries |
| `default_context` | Current context | K8s context to use |
| `timeout` | 30 | Command timeout in seconds |
### AWS
```json theme={null}
{
"tools": {
"aws": {
"enabled": true,
"region": "us-west-2",
"profile": "production",
"assume_role": "arn:aws:iam::123456789:role/incidentfox"
}
}
}
```
| Option | Default | Description |
| ------------- | --------- | ---------------------- |
| `region` | From env | AWS region |
| `profile` | `default` | AWS profile name |
| `assume_role` | None | IAM role ARN to assume |
### Coralogix
```json theme={null}
{
"tools": {
"coralogix": {
"enabled": true,
"api_key": "vault://secrets/coralogix-api-key",
"domain": "coralogix.com",
"default_application": "production",
"default_subsystem": "backend"
}
}
}
```
| Option | Required | Description |
| --------------------- | -------- | ------------------------------------------------------------- |
| `api_key` | Yes | Coralogix API key |
| `domain` | Yes | Coralogix domain (e.g., `coralogix.com`, `eu2.coralogix.com`) |
| `default_application` | No | Default application filter |
| `default_subsystem` | No | Default subsystem filter |
### Snowflake
```json theme={null}
{
"tools": {
"snowflake": {
"enabled": true,
"account": "acme.us-west-2",
"username": "vault://secrets/snowflake-user",
"password": "vault://secrets/snowflake-pass",
"warehouse": "COMPUTE_WH",
"database": "ANALYTICS",
"schema": "PUBLIC",
"role": "ANALYST"
}
}
}
```
| Option | Required | Description |
| ----------- | -------- | ------------------------------ |
| `account` | Yes | Snowflake account identifier |
| `username` | Yes | Username for authentication |
| `password` | Yes | Password (use vault reference) |
| `warehouse` | Yes | Default warehouse |
| `database` | No | Default database |
| `schema` | No | Default schema |
| `role` | No | Snowflake role to use |
### Datadog
```json theme={null}
{
"tools": {
"datadog": {
"enabled": true,
"api_key": "vault://secrets/datadog-api-key",
"app_key": "vault://secrets/datadog-app-key",
"site": "datadoghq.com"
}
}
}
```
| Option | Required | Description |
| --------- | -------- | --------------------------------------- |
| `api_key` | Yes | Datadog API key |
| `app_key` | Yes | Datadog Application key |
| `site` | No | Datadog site (default: `datadoghq.com`) |
### Grafana
```json theme={null}
{
"tools": {
"grafana": {
"enabled": true,
"url": "https://grafana.company.com",
"api_key": "vault://secrets/grafana-api-key",
"default_datasource": "Prometheus"
}
}
}
```
| Option | Required | Description |
| -------------------- | -------- | ------------------------ |
| `url` | Yes | Grafana instance URL |
| `api_key` | Yes | Grafana API key |
| `default_datasource` | No | Default data source name |
### GitHub
```json theme={null}
{
"tools": {
"github": {
"enabled": true,
"token": "vault://secrets/github-token",
"default_org": "acme-corp",
"default_repo": "main-app"
}
}
}
```
| Option | Required | Description |
| -------------- | -------- | ---------------------------- |
| `token` | Yes | GitHub Personal Access Token |
| `default_org` | No | Default organization |
| `default_repo` | No | Default repository |
## Disabling Dangerous Tools
For security, you may want to disable certain tools:
```json theme={null}
{
"agents": {
"investigation_agent": {
"disable_default_tools": [
"shell",
"docker_exec",
"db_write",
"remediation_actions"
]
}
}
}
```
Consider which tools are appropriate for each environment. Production may need stricter controls than staging.
## Tool Loading Priority
When an agent needs a tool, the system checks:
1. **Is the integration installed?** (package availability)
2. **Are credentials configured?** (tool config + vault)
3. **Is it enabled for this team?** (team config)
4. **Is it allowed for this agent?** (agent config)
All conditions must be met for the tool to be available.
## Monitoring Tool Usage
View tool usage metrics in the Web UI under **Team Console** > **Agent Runs**.
Each investigation shows:
* Which tools were invoked
* Execution time per tool
* Success/failure status
* Tool output (redacted as needed)
## Next Steps
Detailed setup for each data source
Add custom tools via MCP
# AWS
Source: https://docs.incidentfox.ai/data-sources/aws
Connect IncidentFox to AWS for CloudWatch, EC2, RDS, Lambda, and more
## Overview
AWS integration enables IncidentFox to access your AWS infrastructure for:
* CloudWatch Logs and Metrics
* EC2 instance status and details
* RDS database monitoring
* Lambda function analysis
* ECS/Fargate task status
* CodePipeline deployment tracking
## Prerequisites
* AWS account with IAM access
* IAM role or user with appropriate permissions
* Knowledge of your AWS region(s)
## Configuration
### Step 1: Create IAM Role (Recommended)
Create an IAM role for IncidentFox to assume:
```json theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "CloudWatchLogs",
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups",
"logs:DescribeLogStreams",
"logs:GetLogEvents",
"logs:FilterLogEvents",
"logs:StartQuery",
"logs:GetQueryResults"
],
"Resource": "*"
},
{
"Sid": "CloudWatchMetrics",
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricData",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics",
"cloudwatch:DescribeAlarms",
"cloudwatch:DescribeAlarmHistory"
],
"Resource": "*"
},
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeInstanceStatus",
"ec2:DescribeVolumes",
"ec2:DescribeNetworkInterfaces"
],
"Resource": "*"
},
{
"Sid": "RDS",
"Effect": "Allow",
"Action": [
"rds:DescribeDBInstances",
"rds:DescribeDBClusters",
"rds:DescribeEvents",
"pi:GetResourceMetrics"
],
"Resource": "*"
},
{
"Sid": "Lambda",
"Effect": "Allow",
"Action": [
"lambda:GetFunction",
"lambda:ListFunctions",
"lambda:GetFunctionConfiguration"
],
"Resource": "*"
},
{
"Sid": "ECS",
"Effect": "Allow",
"Action": [
"ecs:DescribeClusters",
"ecs:DescribeServices",
"ecs:DescribeTasks",
"ecs:ListTasks"
],
"Resource": "*"
},
{
"Sid": "CodePipeline",
"Effect": "Allow",
"Action": [
"codepipeline:GetPipeline",
"codepipeline:GetPipelineState",
"codepipeline:GetPipelineExecution",
"codepipeline:ListPipelineExecutions"
],
"Resource": "*"
}
]
}
```
Adjust the Resource ARNs to limit access to specific resources in production.
### Step 2: Configure Trust Policy
If using cross-account access:
```json theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::INCIDENTFOX_ACCOUNT:role/incidentfox-agent"
},
"Action": "sts:AssumeRole"
}
]
}
```
### Step 3: Add to IncidentFox
**Via Web UI:**
1. Go to **Team Console** > **Integrations**
2. Click **Add Integration** > **AWS**
3. Enter:
* Region (primary)
* Authentication method (Role ARN or Access Keys)
* Role ARN (if using assume role)
4. Click **Test Connection**
5. Save
**Via Configuration:**
```json theme={null}
{
"tools": {
"aws": {
"enabled": true,
"region": "us-west-2",
"assume_role": "arn:aws:iam::123456789:role/incidentfox-readonly"
}
}
}
```
For multiple regions:
```json theme={null}
{
"tools": {
"aws": {
"enabled": true,
"regions": ["us-west-2", "us-east-1"],
"assume_role": "arn:aws:iam::123456789:role/incidentfox-readonly"
}
}
}
```
## Available Tools
### CloudWatch Logs
#### `get_cloudwatch_logs`
Fetch logs from CloudWatch Log Groups.
```
@incidentfox get cloudwatch logs for /aws/lambda/payments-processor from the last hour
```
**Parameters:**
* `log_group` - Log group name
* `filter_pattern` - CloudWatch filter pattern
* `time_range` - Time range to search
#### `query_cloudwatch_insights`
Run CloudWatch Logs Insights queries.
```
@incidentfox run cloudwatch insights query to find error patterns in the last 24 hours
```
**Parameters:**
* `log_groups` - Log groups to query
* `query` - Insights query string
* `time_range` - Time range
**Example Query:**
```sql theme={null}
fields @timestamp, @message
| filter @message like /ERROR/
| stats count(*) as errorCount by bin(1h)
| sort @timestamp desc
```
### CloudWatch Metrics
#### `get_cloudwatch_metrics`
Query CloudWatch metrics.
```
@incidentfox get CPU utilization for the payments EC2 instances over the last 6 hours
```
**Parameters:**
* `namespace` - Metric namespace (e.g., AWS/EC2)
* `metric_name` - Metric name
* `dimensions` - Dimension filters
* `statistic` - Average, Sum, Maximum, etc.
* `period` - Data point period in seconds
### EC2
#### `describe_ec2_instance`
Get EC2 instance details and status.
```
@incidentfox describe EC2 instance i-0123456789abcdef0
```
**Parameters:**
* `instance_id` - EC2 instance ID
**Returns:**
* Instance state
* Instance type
* Launch time
* Security groups
* Network interfaces
* Tags
### RDS
#### `get_rds_instance_status`
Check RDS database status and metrics.
```
@incidentfox check the status of the production RDS instance
```
**Parameters:**
* `db_identifier` - RDS instance identifier
**Returns:**
* Instance status
* Endpoint
* Storage allocation
* Recent events
* Performance metrics
### Lambda
#### `describe_lambda_function`
Get Lambda function configuration.
```
@incidentfox describe the payment-processor Lambda function
```
**Parameters:**
* `function_name` - Lambda function name
**Returns:**
* Runtime
* Memory configuration
* Timeout
* Environment variables
* Last modified
* Recent invocations
### ECS
#### `list_ecs_tasks`
List ECS tasks in a cluster/service.
```
@incidentfox list ECS tasks for the checkout service
```
**Parameters:**
* `cluster` - ECS cluster name
* `service` - Service name (optional)
* `status` - RUNNING, STOPPED, etc.
### CodePipeline
#### `describe_codepipeline`
Get CodePipeline execution status.
```
@incidentfox check the status of the main deployment pipeline
```
**Parameters:**
* `pipeline_name` - Pipeline name
**Returns:**
* Pipeline state
* Stage statuses
* Recent executions
* Failed actions (if any)
## Use Cases
### Investigating Lambda Errors
```
@incidentfox investigate errors in the payment-processor Lambda
IncidentFox will:
1. Check Lambda function configuration
2. Query CloudWatch Logs for errors
3. Get invocation metrics
4. Identify patterns
```
### RDS Performance Issues
```
@incidentfox check RDS performance for the production database
IncidentFox will:
1. Get RDS instance status
2. Query Performance Insights metrics
3. Check connection count
4. Review recent events
```
### Deployment Tracking
```
@incidentfox did any CodePipeline deployments happen in the last 4 hours?
IncidentFox will:
1. List recent pipeline executions
2. Show deployment status
3. Correlate with any incidents
```
## Multi-Account Setup
For organizations with multiple AWS accounts:
```json theme={null}
{
"tools": {
"aws": {
"enabled": true,
"accounts": [
{
"name": "production",
"assume_role": "arn:aws:iam::111111111111:role/incidentfox",
"regions": ["us-west-2", "us-east-1"]
},
{
"name": "staging",
"assume_role": "arn:aws:iam::222222222222:role/incidentfox",
"regions": ["us-west-2"]
}
]
}
}
}
```
## Troubleshooting
### Access Denied
**Symptom:** "User is not authorized to perform this action"
**Solutions:**
1. Verify IAM policy attached to role
2. Check trust relationship allows assume role
3. Ensure resource ARNs match your resources
### No Data Returned
**Symptom:** Queries return empty results
**Solutions:**
1. Verify region is correct
2. Check time range - CloudWatch has retention limits
3. Confirm log group/metric names are exact
### Throttling
**Symptom:** "Rate exceeded" errors
**Solutions:**
1. Reduce query frequency
2. Use broader time periods
3. Request AWS quota increase
## Best Practices
**Use CloudWatch Insights** for complex log analysis - it's faster and more powerful than filter patterns.
1. **Use resource tagging** - Tag resources to enable filtered queries
2. **Set up log retention** - Ensure logs are retained long enough for investigations
3. **Use cross-account roles** - Avoid using access keys
4. **Enable Performance Insights** - For RDS debugging
5. **Set up CloudWatch alarms** - So IncidentFox can reference them
## Next Steps
Connect K8s clusters
Set up Datadog
# Coralogix
Source: https://docs.incidentfox.ai/data-sources/coralogix
Connect IncidentFox to Coralogix for log search, metrics, and alerts
## Overview
Coralogix is a full-stack observability platform. IncidentFox integrates with Coralogix to:
* Search logs across applications and subsystems
* Query metrics for anomaly detection
* Access alert history and context
* Integrate with Olly (Coralogix's AI SRE agent)
## Prerequisites
* Coralogix account with API access
* API key with read permissions
* Knowledge of your Coralogix domain
## Configuration
### Step 1: Create a Coralogix API Key
1. Log in to your Coralogix dashboard
2. Navigate to **Settings** (left navbar) > **API Keys**
3. Click **+ Team Key** (bottom right)
4. Configure the key:
* **Key name:** `IncidentFox` (or any descriptive name)
* **Role Presets:** Select `DataQuerying`
5. Click **Create**
6. Copy the API key
### Step 2: Identify Your Domain
Your Coralogix domain is shown in your browser URL when logged in (e.g., `app.eu2.coralogix.com`).
Coralogix regional domains:
| Region | Team Login URL |
| --------------- | ------------------------- |
| EU1 (Ireland) | `coralogix.com` |
| EU2 (Stockholm) | `app.eu2.coralogix.com` |
| US1 (Ohio) | `app.coralogix.us` |
| US2 (Oregon) | `app.cx498.coralogix.com` |
| AP1 (India) | `app.coralogix.in` |
| AP2 (Singapore) | `app.coralogixsg.com` |
| AP3 (Jakarta) | `app.ap3.coralogix.com` |
### Step 3: Connect to IncidentFox
See [Configuring Data Sources](/integrations/slack#configuring-data-sources) for general instructions on opening the configuration panel in Slack.
1. Open the IncidentFox app in Slack (click the bot's avatar → **Open App**)
2. Under **Available Integrations**, find Coralogix and click **Connect** (or **Edit** if already configured)
3. In the modal:
* Watch the **video walkthrough** for step-by-step guidance
* Paste your **API Key**
* Select your **Domain** from the dropdown (based on your Coralogix URL)
* Optionally, add **Custom Context** to help the AI understand your Coralogix setup (e.g., application names, team conventions, important subsystems)
4. Click **Save**
### Custom Context for AI (Optional)
The **Context for AI** field lets you provide additional information that helps IncidentFox investigate more effectively. Examples:
* "Our main applications are `payments-api` and `checkout-service`"
* "Production logs use subsystem `prod-backend`, staging uses `staging-backend`"
* "Critical alerts come from the `sre-alerts` application"
This context is provided to the AI during investigations to help it query the right data.
## Available Tools
Once configured, these tools become available:
### `search_coralogix_logs`
Search logs with Lucene query syntax.
```
@incidentfox search coralogix logs for "error" AND "payments" in the last hour
```
**Parameters:**
* `query` - Lucene query string
* `application` - Application filter (optional)
* `subsystem` - Subsystem filter (optional)
* `time_range` - Time range (default: 1 hour)
### `get_coralogix_metrics`
Query metrics data.
```
@incidentfox get coralogix metrics for request_latency_p99 in payments service
```
**Parameters:**
* `metric_name` - Name of the metric
* `filters` - Label filters
* `aggregation` - Sum, avg, max, min, etc.
* `time_range` - Time range for query
### `get_coralogix_alerts`
Retrieve recent alerts.
```
@incidentfox show coralogix alerts for the last 24 hours
```
**Parameters:**
* `severity` - Filter by severity (optional)
* `status` - Active, resolved, all
* `time_range` - Time range
### `get_coralogix_traces`
Get distributed traces for a service.
```
@incidentfox get traces for the checkout flow with high latency
```
**Parameters:**
* `service` - Service name
* `operation` - Operation/endpoint (optional)
* `min_duration` - Minimum trace duration
* `time_range` - Time range
## Olly Integration
Coralogix's AI SRE agent, Olly, can work alongside IncidentFox for enhanced investigations.
### How It Works
```mermaid theme={null}
graph LR
A[IncidentFox Agent] --> B[Coralogix API]
B --> C[Olly AI SRE]
C --> D[Enriched Analysis]
D --> A
```
IncidentFox can:
1. Query Coralogix data directly
2. Request Olly's analysis of specific issues
3. Combine Olly's insights with data from other sources
### Example: Combined Investigation
```
@incidentfox investigate high error rates in the checkout service, use Olly for analysis
```
IncidentFox will:
1. Query Coralogix logs for errors
2. Ask Olly to analyze the error patterns
3. Correlate with metrics from other sources
4. Provide combined findings
## Use Cases
### Log Search During Incidents
```
@incidentfox search coralogix for exceptions in payments-service since the alert fired
```
IncidentFox will:
* Query recent logs matching the criteria
* Identify error patterns
* Correlate with recent deployments
### Metrics Correlation
```
@incidentfox check if latency spike in coralogix correlates with database connection issues
```
### Alert Investigation
```
@incidentfox get context for the latest coralogix alert on cart-service
```
## Troubleshooting
### Connection Failed
**Symptom:** "Unable to connect to Coralogix API"
**Solutions:**
1. Verify API key is valid and not expired
2. Check domain is correct for your region
3. Ensure network allows outbound HTTPS to Coralogix
### Empty Results
**Symptom:** Queries return no data
**Solutions:**
1. Verify application/subsystem names are correct
2. Check time range - data may be outside the range
3. Verify the query syntax (Lucene format)
### Rate Limiting
**Symptom:** "Rate limit exceeded" errors
**Solutions:**
1. Reduce query frequency
2. Use more specific queries
3. Contact Coralogix to increase limits
## Best Practices
**Use application and subsystem filters** to narrow results and improve query performance.
1. **Set default filters** in configuration to reduce noise
2. **Use specific time ranges** - don't query more data than needed
3. **Leverage Olly** for pattern recognition in large log volumes
4. **Combine with other sources** - Coralogix for logs, Grafana for metrics
## Security Considerations
### What IncidentFox Can Access
The `DataQuerying` preset grants these **read-only** capabilities:
| Permission | Purpose |
| ----------------------------------- | -------------------------------- |
| Query Data from the Archive | Search historical data |
| Query Frequent Search Logs | Search and analyze log data |
| Query Monitoring & Compliance Logs | Query compliance-tier logs |
| Query Metrics | Correlate metrics with incidents |
| Query Frequent Search Spans | Trace requests across services |
| Query Monitoring & Compliance Spans | Query compliance-tier traces |
| View CPU profiling data | View profiling information |
### What IncidentFox Cannot Do
* Create, modify, or delete alerts
* Change any Coralogix configurations
* Access team admin settings
* Manage API keys or users
* Send or ingest data
### Best Practices
* **All permissions are read-only** - no write or management access
* **You control the key** - revoke anytime from your Coralogix dashboard
* **No data storage** - IncidentFox queries on-demand; logs stay in Coralogix
* Store keys in your secrets manager
* Rotate keys periodically
* Monitor API usage for anomalies
### Revoking Access
To revoke IncidentFox's access at any time:
1. Go to **Settings** > **API Keys** in your Coralogix dashboard
2. Find the `IncidentFox` key
3. Click **Delete**
## Next Steps
Enrich with historical data
Connect AWS CloudWatch
# Datadog
Source: https://docs.incidentfox.ai/data-sources/datadog
Connect IncidentFox to Datadog for metrics, logs, and APM
## Overview
Datadog integration enables IncidentFox to:
* Query metrics and dashboards
* Search logs
* Access APM traces and service maps
* Retrieve monitor/alert status
## Prerequisites
* Datadog account
* API Key and Application Key
* Read permissions for metrics, logs, and APM
## Configuration
### Step 1: Generate API Keys
1. Log in to Datadog
2. Go to **Organization Settings** > **API Keys**
3. Click **New Key** to generate an API Key
4. Go to **Application Keys** tab
5. Click **New Key** to generate an Application Key
The Application Key is tied to a user and determines permissions. Use a service account.
### Step 2: Add to IncidentFox
**Via Web UI:**
1. Go to **Team Console** > **Integrations**
2. Click **Add Integration** > **Datadog**
3. Enter:
* API Key
* Application Key
* Site (e.g., datadoghq.com)
4. Click **Test Connection**
5. Save
**Via Configuration:**
```json theme={null}
{
"tools": {
"datadog": {
"enabled": true,
"api_key": "vault://secrets/datadog-api-key",
"app_key": "vault://secrets/datadog-app-key",
"site": "datadoghq.com"
}
}
}
```
### Datadog Sites
| Region | Site |
| ------ | ------------------- |
| US1 | `datadoghq.com` |
| US3 | `us3.datadoghq.com` |
| US5 | `us5.datadoghq.com` |
| EU | `datadoghq.eu` |
| AP1 | `ap1.datadoghq.com` |
## Available Tools
### `query_datadog_metrics`
Query metrics from Datadog.
```
@incidentfox query datadog metrics for avg:system.cpu.user by service in the last hour
```
**Parameters:**
* `query` - Datadog metrics query
* `from_time` - Start time (Unix timestamp or relative)
* `to_time` - End time
### `search_datadog_logs`
Search logs in Datadog.
```
@incidentfox search datadog logs for status:error service:payments
```
**Parameters:**
* `query` - Log search query
* `indexes` - Log indexes to search
* `time_range` - Time range
### `get_service_apm_metrics`
Get APM metrics for a service.
```
@incidentfox get APM metrics for the checkout service including error rate and latency
```
**Parameters:**
* `service` - Service name
* `env` - Environment (optional)
* `time_range` - Time range
## Use Cases
### Investigating Service Latency
```
@incidentfox investigate high latency in payments service using Datadog
IncidentFox will:
1. Query APM latency metrics
2. Get error rates
3. Check for anomalies
4. Review traces with high duration
```
### Log Analysis
```
@incidentfox search for exceptions in Datadog logs for checkout-api
IncidentFox will:
1. Search logs for error patterns
2. Identify common stack traces
3. Correlate with deployments
```
## Next Steps
Set up Grafana
Configure Coralogix
# Docker
Source: https://docs.incidentfox.ai/data-sources/docker
Connect IncidentFox to Docker for container troubleshooting
## Overview
IncidentFox provides 15 Docker tools for comprehensive container debugging, including logs, stats, exec, and inspection capabilities.
## Tools Available
| Tool | Description |
| --------------------- | ------------------------------------ |
| `docker_ps` | List running containers |
| `docker_logs` | Fetch container logs |
| `docker_inspect` | Inspect container configuration |
| `docker_stats` | Get container resource usage |
| `docker_top` | Show running processes in container |
| `docker_events` | Stream Docker events |
| `docker_diff` | Show filesystem changes in container |
| `docker_exec` | Execute command in running container |
| `docker_images` | List Docker images |
| `docker_networks` | List Docker networks |
| `docker_volumes` | List Docker volumes |
| `docker_compose_ps` | List Compose services |
| `docker_compose_logs` | Get Compose service logs |
| `docker_health` | Check container health status |
| `docker_port` | Show port mappings |
## Configuration
### Local Docker Socket
```json theme={null}
{
"tools": {
"docker": {
"enabled": true,
"socket": "/var/run/docker.sock"
}
}
}
```
### Remote Docker API
```json theme={null}
{
"tools": {
"docker": {
"enabled": true,
"host": "tcp://docker-host:2376",
"tls_verify": true,
"cert_path": "/path/to/certs"
}
}
}
```
## Example Queries
### Check Container Status
```
@incidentfox what containers are running on the app server?
```
### Get Container Logs
```
@incidentfox show me logs from the nginx container for the last 30 minutes
```
### Check Resource Usage
```
@incidentfox what is the CPU and memory usage of the api container?
```
### Execute Diagnostic Command
```
@incidentfox run 'netstat -an' in the web container
```
The `docker_exec` tool requires explicit enablement due to security implications. It's disabled by default.
## Use Cases
### Container Health Investigation
When a container is unhealthy:
1. Check container status with `docker_ps`
2. Review logs with `docker_logs`
3. Inspect configuration with `docker_inspect`
4. Check resource usage with `docker_stats`
### Network Debugging
For connectivity issues:
1. List networks with `docker_networks`
2. Inspect container network settings
3. Use `docker_exec` to run network diagnostics
### Resource Exhaustion
When containers are slow or crashing:
1. Check `docker_stats` for CPU/memory usage
2. Review `docker_events` for OOM kills
3. Analyze `docker_diff` for unexpected file changes
## Security Considerations
### Principle of Least Privilege
| Tool | Risk Level | Recommendation |
| -------------------------------- | ---------- | ------------------------- |
| `docker_ps`, `docker_logs` | Low | Enable by default |
| `docker_stats`, `docker_inspect` | Low | Enable by default |
| `docker_exec` | High | Require approval workflow |
| `docker_events` | Medium | Enable with monitoring |
### Approval Workflow for Exec
```json theme={null}
{
"tools": {
"docker_exec": {
"enabled": true,
"require_approval": true,
"allowed_commands": ["ps", "netstat", "cat /etc/hosts"]
}
}
}
```
## Troubleshooting
### Permission Denied
```
Error: permission denied while trying to connect to Docker socket
```
**Solutions:**
1. Add the IncidentFox service user to the `docker` group
2. Use TCP API with proper authentication
3. Use sudo with proper configuration
### Container Not Found
Ensure container names or IDs are correct. Use `docker_ps` to list available containers.
## Next Steps
For orchestrated containers
Advanced log analysis tools
# Elasticsearch
Source: https://docs.incidentfox.ai/data-sources/elasticsearch
Connect IncidentFox to Elasticsearch for log search and analysis
## Overview
IncidentFox integrates with Elasticsearch for log search, aggregations, and analysis. This is commonly used alongside the ELK stack (Elasticsearch, Logstash, Kibana).
## Tools Available
| Tool | Description |
| --------------------------- | ------------------------------- |
| `search_logs` | Search logs with query DSL |
| `aggregate_errors_by_field` | Aggregate error counts by field |
| `get_log_statistics` | Get log volume statistics |
## Configuration
```json theme={null}
{
"tools": {
"elasticsearch": {
"enabled": true,
"hosts": ["https://elasticsearch.your-domain.com:9200"],
"auth": "vault://secrets/elasticsearch-credentials",
"index_pattern": "logs-*"
}
}
}
```
### With API Key Authentication
```json theme={null}
{
"tools": {
"elasticsearch": {
"enabled": true,
"hosts": ["https://elasticsearch.your-domain.com:9200"],
"api_key": "vault://secrets/elasticsearch-api-key",
"index_pattern": "logs-*"
}
}
}
```
## Authentication Methods
| Method | Configuration |
| ---------- | -------------------------------------------- |
| Basic Auth | `username` and `password` or combined `auth` |
| API Key | `api_key` field |
| Cloud ID | `cloud_id` for Elastic Cloud |
## Example Queries
### Search for Errors
```
@incidentfox search elasticsearch for errors in the payments service
```
### Aggregate by Error Type
```
@incidentfox what are the most common error types in the last hour?
```
### Find Specific Logs
```
@incidentfox find logs containing "connection refused" from the API service
```
## Use Cases
### Error Investigation
When investigating application errors:
1. Search for error logs matching the timeframe
2. Aggregate by error type to find patterns
3. Drill down into specific error instances
### Log Correlation
Correlate logs across services:
1. Search logs from multiple indices
2. Filter by trace ID or request ID
3. Build timeline of events
### Performance Analysis
Analyze slow requests:
1. Search for logs with high latency
2. Aggregate by endpoint or service
3. Identify bottlenecks
## Index Patterns
Configure which indices to search:
```json theme={null}
{
"tools": {
"elasticsearch": {
"index_pattern": "logs-*",
"default_time_field": "@timestamp"
}
}
}
```
### Multiple Index Patterns
```json theme={null}
{
"tools": {
"elasticsearch": {
"index_patterns": {
"application": "app-logs-*",
"system": "syslog-*",
"audit": "audit-*"
}
}
}
}
```
## Required Permissions
Create a role with these permissions:
```json theme={null}
{
"cluster": ["monitor"],
"indices": [
{
"names": ["logs-*"],
"privileges": ["read", "view_index_metadata"]
}
]
}
```
## Troubleshooting
### Connection Issues
```
Error: Unable to connect to Elasticsearch
```
**Solutions:**
1. Verify hosts are reachable
2. Check SSL/TLS configuration
3. Verify authentication credentials
### Slow Queries
For large datasets:
```json theme={null}
{
"tools": {
"elasticsearch": {
"timeout": "60s",
"max_results": 1000
}
}
}
```
## Next Steps
Advanced log analysis tools
Alternative log platform
# Grafana
Source: https://docs.incidentfox.ai/data-sources/grafana
Connect IncidentFox to Grafana for dashboards and Prometheus queries
## Overview
Grafana integration enables IncidentFox to:
* Query Prometheus metrics via Grafana
* Access dashboard data
* Retrieve alert status
* Reference annotations
## Prerequisites
* Grafana instance (Cloud or self-hosted)
* API key with Viewer permissions
* Data sources configured in Grafana
## Configuration
### Step 1: Generate API Key
1. Log in to Grafana
2. Go to **Administration** > **Users and access** > **Service accounts**
3. Create a new service account with **Viewer** role
4. Generate a token for the service account
### Step 2: Add to IncidentFox
**Via Configuration:**
```json theme={null}
{
"tools": {
"grafana": {
"enabled": true,
"url": "https://grafana.company.com",
"api_key": "vault://secrets/grafana-api-key",
"default_datasource": "Prometheus"
}
}
}
```
## Available Tools
### `grafana_query_prometheus`
Query Prometheus via Grafana.
```
@incidentfox query prometheus for request_latency_seconds by service
```
**Parameters:**
* `query` - PromQL query
* `time_range` - Time range
* `step` - Query step
### `grafana_get_dashboard`
Get dashboard panels and data.
```
@incidentfox get the production overview dashboard from Grafana
```
### `grafana_get_alerts`
Check alert status.
```
@incidentfox show firing Grafana alerts
```
## Next Steps
Set up Datadog
Connect K8s
# Kubernetes
Source: https://docs.incidentfox.ai/data-sources/kubernetes
Connect IncidentFox to your Kubernetes clusters
## Overview
Kubernetes integration enables IncidentFox to:
* Fetch pod logs and events
* Describe deployments, services, and pods
* Check resource usage
* Execute commands in containers (if permitted)
## Prerequisites
* Kubernetes cluster access
* kubeconfig file or in-cluster configuration
* RBAC permissions for IncidentFox service account
## Configuration
### Step 1: Create Service Account
Create a service account with read permissions:
```yaml theme={null}
apiVersion: v1
kind: ServiceAccount
metadata:
name: incidentfox
namespace: incidentfox
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: incidentfox-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log", "services", "events", "namespaces"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["deployments", "replicasets", "statefulsets", "daemonsets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["metrics.k8s.io"]
resources: ["pods", "nodes"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: incidentfox-reader
subjects:
- kind: ServiceAccount
name: incidentfox
namespace: incidentfox
roleRef:
kind: ClusterRole
name: incidentfox-reader
apiGroup: rbac.authorization.k8s.io
```
### Step 2: Add to IncidentFox
**Via Configuration:**
```json theme={null}
{
"tools": {
"kubernetes": {
"enabled": true,
"kubeconfig_path": "~/.kube/config",
"default_namespace": "production",
"default_context": "prod-cluster"
}
}
}
```
## Available Tools
### `get_pod_logs`
Fetch logs from pods.
```
@incidentfox get logs from the payments pod in production
```
**Parameters:**
* `pod_name` - Pod name or pattern
* `namespace` - Namespace
* `container` - Container name (optional)
* `tail_lines` - Number of lines
* `since` - Time duration (e.g., "1h")
### `describe_pod`
Get pod details and status.
```
@incidentfox describe pod checkout-abc123 in production
```
### `list_pods`
List pods with status.
```
@incidentfox list pods in the payments namespace
```
### `get_pod_events`
Get Kubernetes events for pods.
```
@incidentfox get events for the cart deployment
```
### `describe_deployment`
Get deployment status and replicas.
```
@incidentfox describe the payments deployment
```
### `get_pod_resource_usage`
Check CPU and memory usage.
```
@incidentfox check resource usage for pods in production namespace
```
Requires metrics-server installed in the cluster.
## Use Cases
### Pod Crash Investigation
```
@incidentfox investigate why cart pods are crashing
IncidentFox will:
1. List pods and their status
2. Get events showing crash reasons
3. Fetch logs before crash
4. Check resource usage
5. Identify root cause
```
### Deployment Rollout Issues
```
@incidentfox check the payments deployment rollout status
IncidentFox will:
1. Describe deployment
2. Check replica status
3. Get events for issues
4. Review pod logs
```
## Next Steps
Connect AWS
See all K8s tools
# Data Sources Overview
Source: https://docs.incidentfox.ai/data-sources/overview
Connect IncidentFox to your observability stack
## Overview
IncidentFox connects to your existing observability and data platforms to investigate incidents. This section covers how to configure each data source.
## Supported Data Sources
### Observability Platforms
| Platform | Status | Capabilities |
| -------------------------------------------- | --------- | --------------------------------------------------- |
| [Coralogix](/data-sources/coralogix) | Supported | Log search, metrics, alerts, Olly integration |
| [Datadog](/data-sources/datadog) | Supported | Metrics, logs, APM traces |
| [Grafana](/data-sources/grafana) | Supported | Prometheus queries, dashboards, alerts, annotations |
| [Prometheus](/data-sources/prometheus) | Supported | PromQL queries, instant queries, alerts |
| [Sentry](/data-sources/sentry) | Supported | Error tracking, issues, project stats, releases |
| [New Relic](/data-sources/newrelic) | Supported | NRQL queries, APM summary |
| [Elasticsearch](/data-sources/elasticsearch) | Supported | Log search, aggregations |
| [Splunk](/data-sources/splunk) | Supported | SPL queries, log search |
| Loki | Supported | LogQL queries |
### Cloud Providers
| Platform | Status | Capabilities |
| ---------------------------- | --------- | ----------------------------------------------- |
| [AWS](/data-sources/aws) | Supported | CloudWatch, EC2, Lambda, RDS, ECS, CodePipeline |
| [Azure](/data-sources/azure) | Supported | Monitor, VMs, App Services |
| [GCP](/data-sources/gcp) | Supported | Cloud Logging, Compute, Cloud Run |
### Infrastructure
| Platform | Status | Capabilities |
| -------------------------------------- | --------- | ------------------------------------------------------- |
| [Kubernetes](/data-sources/kubernetes) | Supported | Pod logs, events, deployments, metrics |
| [Docker](/data-sources/docker) | Supported | Container logs, exec, stats, events, inspect (15 tools) |
| Terraform | Supported | State inspection, planning |
### Databases
| Platform | Status | Capabilities |
| -------------------------------------- | --------- | ---------------------------------- |
| [Snowflake](/data-sources/snowflake) | Supported | SQL queries, data enrichment |
| [PostgreSQL](/data-sources/postgresql) | Supported | Query execution, schema inspection |
| [MySQL](/data-sources/mysql) | Supported | Query execution, schema inspection |
| [BigQuery](/data-sources/bigquery) | Supported | SQL queries, analytics |
### Code & CI/CD
| Platform | Status | Capabilities |
| -------- | --------- | ------------------------------------------------------- |
| GitHub | Supported | Code search, PRs, Actions, commits, webhooks (16 tools) |
| GitLab | Supported | Repositories, merge requests |
| Jenkins | Supported | Build status, logs |
### Documentation & Knowledge
| Platform | Status | Capabilities |
| ----------- | --------- | --------------------------- |
| Confluence | Supported | Wiki search, page retrieval |
| Notion | Supported | Workspace search |
| Google Docs | Supported | Runbook search |
### Messaging & Streaming
| Platform | Status | Capabilities |
| --------------- | --------- | ------------------------------ |
| Kafka | Supported | Topic inspection, consumer lag |
| Debezium | Supported | CDC monitoring |
| Schema Registry | Supported | Schema management |
## Data Source Architecture
```mermaid theme={null}
graph TD
subgraph IncidentFox
A[K8s Agent]
B[AWS Agent]
C[Metrics Agent]
D[Coding Agent]
E[Investigation Agent]
end
A --> F[Kubernetes Cluster]
A --> G[Docker]
B --> H[AWS CloudWatch/EC2/RDS]
C --> I[Prometheus/Grafana/Datadog]
C --> J[Sentry/New Relic]
D --> K[GitHub/GitLab]
E --> L[Elasticsearch/Splunk]
E --> M[Snowflake/PostgreSQL/BigQuery]
```
## Credential Management
All credentials should be stored securely using vault references:
```json theme={null}
{
"tools": {
"coralogix": {
"api_key": "vault://secrets/coralogix-api-key"
}
}
}
```
Never store credentials in plain text in configuration files.
### Vault Reference Format
```
vault://path/to/secret
```
IncidentFox supports:
* AWS Secrets Manager
* HashiCorp Vault
* Environment variables (for development)
## Quick Setup
Identify which platforms you want IncidentFox to access
Generate read-only API keys for each platform
Add credentials to your secrets manager
Add data source configuration in Team Console
Verify IncidentFox can access each data source
## Required Permissions
Each data source requires specific permissions. Generally, IncidentFox needs **read-only** access for investigation.
| Data Source | Required Permissions |
| ------------- | ---------------------------------------------------- |
| Coralogix | API key with read access |
| AWS | CloudWatch read, EC2 describe, RDS read, Lambda read |
| Kubernetes | Pod logs, events, describe resources |
| GitHub | Repo read, issues read, PRs read |
| Snowflake | SELECT on relevant tables |
| Datadog | API key + App key with read access |
| Prometheus | Query access to /api/v1/query endpoint |
| Grafana | Viewer role, API key with read access |
| Sentry | Project read, issue read |
| Elasticsearch | Read access to indices |
| PostgreSQL | SELECT on relevant tables |
| Docker | Docker socket access or API access |
**Principle of least privilege**: Only grant permissions that are necessary for investigation. IncidentFox doesn't need write access unless you enable auto-remediation.
## Data Flow
When IncidentFox investigates an incident:
1. **Agent determines** which data sources are relevant
2. **Tools are invoked** to query each data source
3. **Data is retrieved** and processed locally
4. **Results are correlated** across sources
5. **Findings are reported** back to the user
Data is:
* Retrieved on-demand (not continuously polled)
* Processed in-memory (not stored long-term)
* Filtered by time range (typically last 1-24 hours)
## Next Steps
Connect your Coralogix account
Set up data enrichment
Configure AWS access
Connect to your clusters
# Prometheus
Source: https://docs.incidentfox.ai/data-sources/prometheus
Connect IncidentFox to Prometheus for metrics queries and alerting
## Overview
IncidentFox integrates with Prometheus for metrics queries, instant queries, and alert management. This includes support for Alertmanager for alert correlation.
## Tools Available
| Tool | Description |
| -------------------------- | ------------------------------------ |
| `query_prometheus` | Execute PromQL range queries |
| `prometheus_instant_query` | Execute instant PromQL queries |
| `get_prometheus_alerts` | Get configured alert rules |
| `get_alertmanager_alerts` | Get currently firing alerts |
| `get_active_alerts` | Get all active alerts across sources |
## Configuration
### Basic Setup
```json theme={null}
{
"tools": {
"prometheus": {
"enabled": true,
"url": "https://prometheus.your-domain.com",
"auth": "vault://secrets/prometheus-token"
}
}
}
```
### With Alertmanager
```json theme={null}
{
"tools": {
"prometheus": {
"enabled": true,
"url": "https://prometheus.your-domain.com",
"alertmanager_url": "https://alertmanager.your-domain.com",
"auth": "vault://secrets/prometheus-token"
}
}
}
```
## Authentication
Prometheus supports several authentication methods:
| Method | Configuration |
| ------------ | --------------------------------- |
| Bearer Token | `auth: "vault://secrets/token"` |
| Basic Auth | `username` and `password` fields |
| No Auth | Omit auth field (not recommended) |
## Example Queries
### PromQL Range Query
```
@incidentfox query prometheus for CPU usage of the payments service over the last hour
```
IncidentFox executes:
```promql theme={null}
rate(container_cpu_usage_seconds_total{service="payments"}[5m])
```
### Check Firing Alerts
```
@incidentfox what alerts are currently firing?
```
### Correlate with Metrics
```
@incidentfox correlate the error rate spike with any metric anomalies
```
## Use Cases
### Anomaly Detection
IncidentFox uses Prometheus metrics for anomaly detection:
1. Queries historical data for baseline
2. Applies Z-score or Prophet-based detection
3. Identifies deviations from normal behavior
### Alert Correlation
When investigating incidents, IncidentFox:
1. Fetches currently firing alerts from Alertmanager
2. Correlates alert timing with incident timeline
3. Identifies related alerts across services
### Capacity Planning
Use the forecasting tools with Prometheus data:
```
@incidentfox forecast disk usage for the next 7 days
```
## Required Permissions
| Component | Permission |
| ------------ | --------------------------------------------------------- |
| Prometheus | Query access to `/api/v1/query` and `/api/v1/query_range` |
| Alertmanager | Read access to `/api/v2/alerts` |
## Troubleshooting
### Connection Issues
```
Error: Failed to connect to Prometheus
```
**Solutions:**
1. Verify the URL is correct and accessible
2. Check authentication credentials
3. Ensure network connectivity from IncidentFox
### Query Timeouts
For large queries, increase the timeout:
```json theme={null}
{
"tools": {
"prometheus": {
"timeout_seconds": 60
}
}
}
```
## Next Steps
Query Prometheus via Grafana
Use anomaly detection tools
# Sentry
Source: https://docs.incidentfox.ai/data-sources/sentry
Connect IncidentFox to Sentry for error tracking and issue analysis
## Overview
IncidentFox integrates with Sentry for error tracking, issue analysis, and release correlation. This helps identify application errors that may be causing incidents.
## Tools Available
| Tool | Description |
| -------------------------- | --------------------------------------- |
| `sentry_list_issues` | List issues in a project |
| `sentry_get_issue_details` | Get detailed information about an issue |
| `sentry_list_projects` | List all Sentry projects |
| `sentry_get_project_stats` | Get error statistics for a project |
| `sentry_list_releases` | List releases and deployment info |
## Configuration
```json theme={null}
{
"tools": {
"sentry": {
"enabled": true,
"organization": "your-org-slug",
"auth_token": "vault://secrets/sentry-token"
}
}
}
```
## Authentication
Create a Sentry API token with the following scopes:
| Scope | Purpose |
| -------------- | ----------------------------- |
| `project:read` | List and view projects |
| `event:read` | View issue details and events |
| `org:read` | View organization info |
## Example Queries
### Find Recent Errors
```
@incidentfox what errors are occurring in the checkout service?
```
### Correlate with Deployment
```
@incidentfox did the latest release introduce any new errors?
```
### Get Issue Details
```
@incidentfox show me details about Sentry issue PROJ-1234
```
## Use Cases
### Error Spike Investigation
When investigating latency or availability issues:
1. IncidentFox checks Sentry for recent error spikes
2. Correlates error timing with incident timeline
3. Identifies specific exceptions causing problems
### Release Impact Analysis
After a deployment:
1. Compare error rates before/after release
2. Identify new error types introduced
3. Correlate with GitHub commits in the release
### Root Cause Identification
Sentry provides stack traces that help identify:
* Specific code paths causing errors
* Environment differences (e.g., specific hosts)
* User impact scope
## Configuration Options
| Option | Description | Default |
| ----------------- | ------------------------------ | -------- |
| `organization` | Sentry organization slug | Required |
| `auth_token` | API authentication token | Required |
| `default_project` | Default project for queries | Optional |
| `environment` | Filter to specific environment | Optional |
## Troubleshooting
### Rate Limiting
Sentry has API rate limits. If you hit them:
```json theme={null}
{
"tools": {
"sentry": {
"rate_limit_retry": true,
"max_retries": 3
}
}
}
```
### Missing Events
If recent events aren't appearing:
1. Check Sentry data retention settings
2. Verify the project has events
3. Ensure the time range is correct
## Next Steps
Correlate errors with code changes
Combine with log analysis
# Snowflake
Source: https://docs.incidentfox.ai/data-sources/snowflake
Use Snowflake data to enrich incident investigations
## Overview
Snowflake integration allows IncidentFox to query historical data, enrichment tables, and analytics to provide deeper context during investigations.
Common use cases:
* Query historical incident patterns
* Look up customer or service metadata
* Access aggregated metrics not in real-time systems
* Retrieve business context for impact assessment
## Prerequisites
* Snowflake account with API access
* User account with SELECT permissions on relevant tables
* Knowledge of your data schema
## Configuration
### Step 1: Create a Service Account
1. Log in to Snowflake as an admin
2. Create a dedicated user for IncidentFox:
```sql theme={null}
-- Create user
CREATE USER incidentfox_reader
PASSWORD = 'secure_password_here'
DEFAULT_ROLE = INCIDENTFOX_ROLE
DEFAULT_WAREHOUSE = COMPUTE_WH;
-- Create role with limited permissions
CREATE ROLE INCIDENTFOX_ROLE;
-- Grant read access to relevant schemas
GRANT USAGE ON WAREHOUSE COMPUTE_WH TO ROLE INCIDENTFOX_ROLE;
GRANT USAGE ON DATABASE ANALYTICS TO ROLE INCIDENTFOX_ROLE;
GRANT USAGE ON SCHEMA ANALYTICS.OBSERVABILITY TO ROLE INCIDENTFOX_ROLE;
GRANT SELECT ON ALL TABLES IN SCHEMA ANALYTICS.OBSERVABILITY TO ROLE INCIDENTFOX_ROLE;
GRANT SELECT ON FUTURE TABLES IN SCHEMA ANALYTICS.OBSERVABILITY TO ROLE INCIDENTFOX_ROLE;
-- Assign role to user
GRANT ROLE INCIDENTFOX_ROLE TO USER incidentfox_reader;
```
### Step 2: Identify Your Account
Your Snowflake account identifier is in the format:
```
.
```
Example: `acme.us-west-2`
### Step 3: Add to IncidentFox
**Via Web UI:**
1. Go to **Team Console** > **Integrations**
2. Click **Add Integration** > **Snowflake**
3. Enter:
* Account identifier
* Username
* Password (or key pair)
* Default warehouse
* Default database (optional)
* Default schema (optional)
4. Click **Test Connection**
5. Save
**Via Configuration:**
```json theme={null}
{
"tools": {
"snowflake": {
"enabled": true,
"account": "acme.us-west-2",
"username": "vault://secrets/snowflake-user",
"password": "vault://secrets/snowflake-pass",
"warehouse": "COMPUTE_WH",
"database": "ANALYTICS",
"schema": "OBSERVABILITY",
"role": "INCIDENTFOX_ROLE"
}
}
}
```
## Available Tools
### `query_snowflake`
Execute SQL queries against Snowflake.
```
@incidentfox query snowflake for error counts by service in the last 7 days
```
**Parameters:**
* `query` - SQL query to execute
* `warehouse` - Warehouse to use (optional, uses default)
* `timeout` - Query timeout in seconds
### `get_snowflake_schema`
Retrieve table schemas for query building.
```
@incidentfox show the schema for the error_logs table in snowflake
```
## Example Queries
### Historical Error Patterns
```sql theme={null}
SELECT
service_name,
error_type,
COUNT(*) as error_count,
DATE_TRUNC('hour', timestamp) as hour
FROM analytics.observability.error_logs
WHERE timestamp > DATEADD('day', -7, CURRENT_TIMESTAMP())
GROUP BY service_name, error_type, hour
ORDER BY hour DESC, error_count DESC
LIMIT 100
```
### Customer Impact Assessment
```sql theme={null}
SELECT
customer_tier,
COUNT(DISTINCT customer_id) as affected_customers,
SUM(transaction_value) as affected_revenue
FROM analytics.business.transactions t
JOIN analytics.business.customers c ON t.customer_id = c.id
WHERE t.service = 'payments'
AND t.status = 'failed'
AND t.timestamp > DATEADD('hour', -1, CURRENT_TIMESTAMP())
GROUP BY customer_tier
```
### Deployment Correlation
```sql theme={null}
SELECT
d.service,
d.version,
d.deployed_at,
COUNT(e.id) as errors_after_deploy
FROM analytics.devops.deployments d
LEFT JOIN analytics.observability.errors e
ON e.service = d.service
AND e.timestamp BETWEEN d.deployed_at AND DATEADD('hour', 4, d.deployed_at)
WHERE d.deployed_at > DATEADD('day', -1, CURRENT_TIMESTAMP())
GROUP BY d.service, d.version, d.deployed_at
ORDER BY d.deployed_at DESC
```
## Use Cases
### Enriching Incident Context
When investigating an incident, IncidentFox can query Snowflake to:
1. **Get historical baseline** - "Is this error rate normal?"
2. **Identify patterns** - "Has this happened before?"
3. **Assess business impact** - "How many customers are affected?"
4. **Correlate with changes** - "What deployed recently?"
### Example Investigation Flow
```
User: @incidentfox investigate high error rate in checkout
IncidentFox:
1. Queries Coralogix for current errors
2. Queries Snowflake for historical error baseline
3. Queries Snowflake for recent deployments
4. Correlates findings
Result: "Error rate is 10x normal baseline. This matches a pattern
seen after v2.3.1 deployment last month. Current deployment v2.5.0
went out 45 minutes ago. Recommend rollback."
```
## Recommended Tables
For optimal IncidentFox usage, consider creating these Snowflake tables:
### Error Summary Table
```sql theme={null}
CREATE TABLE analytics.observability.error_summary (
timestamp TIMESTAMP,
service VARCHAR,
error_type VARCHAR,
error_count INTEGER,
affected_users INTEGER,
PRIMARY KEY (timestamp, service, error_type)
);
```
### Deployment History
```sql theme={null}
CREATE TABLE analytics.devops.deployments (
id VARCHAR PRIMARY KEY,
service VARCHAR,
version VARCHAR,
deployed_at TIMESTAMP,
deployed_by VARCHAR,
commit_sha VARCHAR,
rollback_of VARCHAR
);
```
### Service Metadata
```sql theme={null}
CREATE TABLE analytics.metadata.services (
name VARCHAR PRIMARY KEY,
team VARCHAR,
criticality VARCHAR, -- P0, P1, P2, P3
oncall_group VARCHAR,
documentation_url VARCHAR,
dependencies ARRAY
);
```
## Query Guardrails
IncidentFox applies safety limits to Snowflake queries:
| Guardrail | Default | Description |
| ------------- | ------------ | ---------------------------- |
| Query timeout | 30s | Maximum query execution time |
| Result limit | 10,000 rows | Maximum rows returned |
| Cost limit | Configurable | Maximum credits per query |
### Configuring Limits
```json theme={null}
{
"tools": {
"snowflake": {
"query_timeout": 30,
"max_rows": 10000,
"cost_limit": 1.0
}
}
}
```
## Troubleshooting
### Connection Failed
**Symptom:** "Unable to connect to Snowflake"
**Solutions:**
1. Verify account identifier format
2. Check username/password
3. Ensure warehouse is running (not suspended)
4. Verify network allows outbound to Snowflake
### Permission Denied
**Symptom:** "Insufficient privileges to execute query"
**Solutions:**
1. Verify role has SELECT on required tables
2. Check role is granted to user
3. Verify database/schema usage grants
### Query Timeout
**Symptom:** "Query execution timed out"
**Solutions:**
1. Optimize query (add filters, limit scope)
2. Increase timeout setting
3. Use a larger warehouse
4. Pre-aggregate data into summary tables
## Best Practices
**Create summary tables** for common queries to reduce execution time and cost.
1. **Use read-only role** - Never grant write permissions
2. **Set warehouse auto-suspend** - Control costs
3. **Pre-aggregate data** - Create hourly/daily summaries
4. **Index timestamp columns** - Most queries filter by time
5. **Limit query scope** - Always include time bounds
## Security Considerations
* Use key pair authentication when possible
* Store credentials in secrets manager
* Use role-based access control
* Enable Snowflake audit logging
* Regularly review access patterns
## Next Steps
Connect AWS CloudWatch
Set up log search
# How It Works
Source: https://docs.incidentfox.ai/how-it-works
Understanding IncidentFox's dual-runtime architecture and RAPTOR knowledge system
## Architecture Overview
IncidentFox uses a sophisticated dual-runtime architecture with two complementary agent systems:
1. **OpenAI SDK Agent** - Multi-agent orchestration for production automation
2. **Claude SDK SRE Agent** - Interactive debugging with Kubernetes sandbox isolation
Both systems share access to 300+ tools and the RAPTOR knowledge base.
```mermaid theme={null}
graph TD
subgraph "External Services"
A[Slack]
B[GitHub]
C[PagerDuty]
end
subgraph "IncidentFox"
D[Orchestrator
Webhook routing, auth]
E[OpenAI SDK Agent
Production automation]
F[Claude SDK SRE Agent
Interactive debugging]
G[Config Service
Multi-tenant config]
H[RAPTOR Knowledge Base
Hierarchical retrieval]
I[Web UI
Dashboard]
end
A --> D
B --> D
C --> D
D --> E
D --> F
E --> G
F --> G
E --> H
F --> H
I --> G
```
## Dual Agent Runtimes
### OpenAI SDK Agent (Production Automation)
The production agent uses multi-agent orchestration where specialized agents collaborate:
```mermaid theme={null}
graph TD
A[Planner Agent
Orchestrates investigations] --> B[K8s Agent
9 tools]
A --> C[AWS Agent
8+ tools]
A --> D[Metrics Agent
22+ tools]
A --> E[Coding Agent
15+ tools]
A --> F[Investigation Agent
300+ tools]
```
**Key characteristics:**
* Automated investigation triggered by webhooks
* Multi-agent orchestration for parallel data gathering
* Optimized for production incident response
* Async execution with status updates
### Claude SDK SRE Agent (Interactive Debugging)
The interactive agent provides hands-on debugging with enhanced security:
**Key characteristics:**
* Kubernetes sandbox isolation with gVisor
* Interactive mode with interrupt/resume support
* Streaming responses for real-time feedback
* Credentials proxy (Envoy) - secrets never touch agent
* Ideal for complex, exploratory investigations
## The Agents
### Planner Agent
The Planner is the orchestrator. When you trigger an investigation, it:
1. **Analyzes the request** - Understands what you're asking
2. **Creates a plan** - Determines which agents and tools are needed
3. **Delegates tasks** - Assigns work to specialized agents
4. **Synthesizes results** - Combines findings into a coherent response
The Planner doesn't execute tools directly. It coordinates other agents that have the specialized capabilities.
### K8s Agent
Specializes in Kubernetes troubleshooting with 9 dedicated tools:
| Tool | Description |
| ------------------------ | ------------------------------------------ |
| `get_pod_logs` | Fetch container logs from pods |
| `describe_pod` | Get pod status, events, and configuration |
| `list_pods` | List pods in a namespace with status |
| `get_pod_events` | Get Kubernetes events for pods |
| `describe_deployment` | Get deployment status and replica info |
| `get_deployment_history` | View rollout history |
| `describe_service` | Get service details and endpoints |
| `get_pod_resource_usage` | CPU/memory usage metrics |
| `propose_pod_restart` | Suggest pod restart with approval workflow |
### AWS Agent
Handles AWS infrastructure debugging with 8+ tools:
| Tool | Description |
| --------------------------- | ------------------------------------- |
| `describe_ec2_instance` | EC2 instance details and status |
| `get_cloudwatch_logs` | Fetch logs from CloudWatch Log Groups |
| `describe_lambda_function` | Lambda configuration and metrics |
| `get_rds_instance_status` | RDS database status and metrics |
| `query_cloudwatch_insights` | Run CloudWatch Insights queries |
| `get_cloudwatch_metrics` | Query CloudWatch metrics |
| `list_ecs_tasks` | List ECS Fargate tasks |
| `describe_codepipeline` | Get CodePipeline execution status |
### Metrics Agent
Focuses on anomaly detection and correlation with 22+ tools including:
* **Anomaly Detection** - Z-score, Prophet-based seasonal detection
* **Correlation Analysis** - Pearson correlation between metrics
* **Change Point Detection** - Identify when metrics behavior changed
* **Forecasting** - Prophet-based capacity planning
* **Trend Decomposition** - Separate trend, seasonality, and residuals
### Coding Agent
Handles code analysis and CI/CD with 15+ tools:
* **File Operations** - Read, search, and analyze code
* **Git Operations** - Diff, blame, log, recent changes analysis
* **GitHub Integration** - PR analysis, code search, commit correlation
* **Test Execution** - Run tests and analyze failures
### Investigation Agent
The "jack of all trades" agent with access to all 300+ tools. Used for complex, cross-domain investigations that require multiple types of analysis.
## RAPTOR Knowledge Base
IncidentFox uses RAPTOR (Recursive Abstractive Processing for Tree-Organized Retrieval), a hierarchical knowledge system based on ICLR 2024 research.
### Why RAPTOR?
Traditional RAG (Retrieval Augmented Generation) struggles with:
* Long documents (100+ page runbooks)
* Complex relationships between concepts
* Multi-level reasoning
RAPTOR solves this with hierarchical abstraction:
```mermaid theme={null}
graph TD
A[Raw Documents
Runbooks, Postmortems] --> B[Chunking]
B --> C[Clustering]
C --> D[Summarization]
D --> E[Abstraction Levels]
E --> F[Tree Structure]
F --> G[Retrieval]
```
### Knowledge Types
| Level | Type | Description |
| ----- | ---------- | ---------------------------------- |
| L1 | Procedural | Step-by-step runbooks |
| L2 | Factual | Service configurations, thresholds |
| L3 | Temporal | Past incidents, timelines |
| L4 | Policy | Escalation rules, SLAs |
### Knowledge Graph
Beyond tree structure, IncidentFox maintains a knowledge graph for:
* Service dependencies
* Team ownership
* Expertise mapping
* Related investigations
### Learning from Investigations
IncidentFox improves over time by:
1. **Recording patterns** - Stores cause-solution pairs from successful investigations
2. **Finding similar incidents** - Matches new issues to past investigations
3. **Importance scoring** - Uses 9+ signals to rank knowledge relevance
4. **Contextual boosts** - Adjusts relevance based on current investigation context
## Investigation Flow
Here's what happens when you trigger an investigation:
User mentions `@incidentfox` in Slack with a request like "investigate high latency in payments service"
RAPTOR retrieves relevant runbooks, past incidents, and service documentation
The Planner agent analyzes the request and determines:
* What systems might be involved (payments, database, etc.)
* What data sources to query (logs, metrics, recent changes)
* Which specialized agents to involve
Specialized agents execute their tools in parallel:
* K8s Agent checks pod status and logs
* AWS Agent queries CloudWatch metrics
* Metrics Agent runs anomaly detection
* Git tools correlate with recent deployments
The Investigation Agent correlates findings:
* Timeline reconstruction
* Root cause identification
* Impact assessment (blast radius)
Results are synthesized and posted back to Slack with:
* Summary of findings
* Root cause with confidence score
* Evidence (logs, metrics, events)
* Recommended actions
If the investigation was successful, patterns are recorded for future use
## Investigation Results
Investigations return structured results:
```json theme={null}
{
"success": true,
"findings": "Payment service latency spike correlated with database connection exhaustion",
"root_cause": "RDS connection pool at 100% capacity following deployment",
"confidence": 92,
"recommendations": [
"Increase max_connections on RDS",
"Review connection pool settings in app config"
],
"phase_results": {
"data_collection": "completed",
"anomaly_detection": "completed",
"root_cause_analysis": "completed",
"impact_assessment": "completed"
},
"duration_seconds": 45.2
}
```
### Finding Types
| Type | Description |
| ---------------- | --------------------------------- |
| `metric_anomaly` | Unusual metric behavior detected |
| `log_error` | Error pattern in logs |
| `event` | System event correlation |
| `hypothesis` | Generated theory about root cause |
| `contradiction` | Conflicting evidence detected |
## Configuration Inheritance
IncidentFox uses hierarchical configuration that flows from organization to team level:
```mermaid theme={null}
graph TD
A[Organization Defaults] --> B[Business Unit Config
optional]
B --> C[Team Config]
```
Each level can override settings from the level above. This allows:
* **Org-wide defaults** - Set sensible defaults for all teams
* **Business unit settings** - Configure for platform vs. application teams
* **Team overrides** - Fine-tune for specific team needs
### Example Configuration Flow
```json theme={null}
// Organization level
{
"mcp_servers": ["grafana", "aws"],
"agents": {
"investigation_agent": {
"prompt": "You are an SRE investigation agent..."
}
}
}
// Team level override
{
"mcp_servers": ["grafana", "aws", "coralogix"], // Added coralogix
"agents": {
"investigation_agent": {
"enable_extra_tools": ["snowflake"] // Team-specific
}
}
}
```
The team's effective config merges both, so they get:
* All three MCP servers
* The org's base prompt
* The snowflake tool enabled
## Data Flow
```mermaid theme={null}
graph LR
A[Trigger
Slack, GitHub, PagerDuty] --> B[Orchestrator]
B --> C[Agent Runtime]
C --> D[Tools Execute]
C --> E[Config Service]
C --> F[Knowledge Base]
D --> G[Data Sources
Prometheus, Datadog, AWS, K8s]
```
1. **Triggers** send investigation requests to the Orchestrator
2. **Orchestrator** routes to appropriate agent runtime
3. **Config Service** provides team-specific configuration
4. **Knowledge Base** provides relevant context
5. **Tools** query external data sources
6. **Results** flow back through the agent to the trigger source
## Tool Loading
Tools are loaded dynamically based on:
1. **Installation** - Is the integration package installed?
2. **Configuration** - Are credentials configured?
3. **Team Settings** - Is the tool enabled for this team?
```python theme={null}
# Example: Tool loading logic
if is_integration_available("coralogix"):
if config.coralogix.api_key:
if "coralogix" not in config.disabled_tools:
load_coralogix_tools()
```
This means teams only see tools relevant to their stack.
## MCP Integration
IncidentFox supports the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) for extending capabilities with custom tools.
### What is MCP?
MCP is an open protocol that allows AI agents to access external tools and data sources in a standardized way. IncidentFox is compatible with 100+ MCP servers.
### Using MCP with IncidentFox
1. **Configure MCP servers** at org or team level
2. **Tools auto-load** without code changes
3. **Agents automatically** discover and use MCP tools during investigations
```json theme={null}
{
"mcp_servers": [
{
"name": "internal-tools",
"url": "mcps://tools.internal.company.com",
"auth": "vault://secrets/mcp-token"
}
]
}
```
### MCP Inheritance
MCP servers configured at the organization level are inherited by all teams. Teams can add additional servers specific to their needs.
## Security Architecture
### Credentials Proxy
Secrets never touch the agent directly:
```mermaid theme={null}
graph LR
A[Agent] --> B[Envoy Proxy]
B --> C[Credential Resolver]
C --> D[Secrets Manager]
B --> E[External API]
```
1. Agent makes API call through Envoy proxy
2. Envoy intercepts and injects credentials at request time
3. Secrets are never stored in agent memory
### Claude Sandbox Isolation
The Claude SDK SRE Agent runs in an isolated Kubernetes environment:
* **gVisor** - User-space kernel for container isolation
* **Network policies** - Restricted egress
* **Resource limits** - CPU, memory, and time bounds
* **Ephemeral** - Sandboxes destroyed after investigation
## Next Steps
Learn how to configure agents and tools
Connect your observability stack
Configure RAPTOR and teach custom knowledge
Understand security architecture
# IncidentFox
Source: https://docs.incidentfox.ai/index
AI-powered incident investigation and infrastructure automation
# Welcome to IncidentFox
IncidentFox is an AI SRE / AI On-Call engineer that integrates with your observability stack, infrastructure, and collaboration tools to automatically investigate incidents, find root causes, and suggest fixes.
Get IncidentFox up and running in minutes
Understand the multi-agent architecture
Configure agents, tools, and prompts
Connect to Slack, GitHub, PagerDuty, and more
## Key Features
IncidentFox uses two powerful agent runtimes:
* **OpenAI SDK Agent** - Production automation with multi-agent orchestration (Planner + Specialists)
* **Claude SDK SRE Agent** - Interactive debugging with Kubernetes sandbox isolation
Specialized agents include K8s, AWS, Metrics, Coding, and Investigation agents working together.
Pre-built integrations across 20+ categories:
* **Kubernetes**: Pod logs, events, deployments, resource usage (9 tools)
* **AWS**: EC2, Lambda, RDS, ECS, CloudWatch (8+ tools)
* **Observability**: Grafana, Datadog, Prometheus, Coralogix, Sentry, New Relic (15+ tools)
* **Log Analysis**: Statistics, sampling, pattern search, anomaly detection (7 tools)
* **Docker**: Container logs, stats, exec, events (15 tools)
* **GitHub**: Code search, PRs, issues, Actions, commits (16 tools)
* **Database**: MySQL, PostgreSQL, Snowflake, BigQuery (70+ tools)
* **And more**: PagerDuty, Slack, Linear, Jira, Confluence, Terraform...
Hierarchical knowledge retrieval system based on ICLR 2024 research:
* Handles 100+ page runbooks without context loss
* Knowledge graphs for service dependencies and ownership
* Learns from past investigations to improve over time
* Multi-level abstraction: procedural, factual, temporal, policy
Invoke IncidentFox from wherever your team works:
* **Slack** - Mention the bot in any channel
* **GitHub** - Comment on issues or PRs
* **PagerDuty** - Automatic investigation on alerts
* **Incident.io** - Integrated incident response
* **REST API** - Programmatic access
* **Web UI** - Dashboard for investigations and configuration
Intelligent analysis powered by state-of-the-art ML:
* **Anomaly Detection** - Z-score, Prophet-based seasonal detection
* **Forecasting** - Capacity planning with uncertainty bounds
* **Correlation Analysis** - Cross-service metric relationships
* **Change Point Detection** - Identify when issues started
* **Pattern Learning** - Records and reuses incident patterns
Built for enterprise security and compliance:
* SOC 2 compliant infrastructure
* Claude Sandbox isolation with Kubernetes + gVisor
* Credentials proxy (Envoy) - secrets never touch agent
* SSO/OIDC authentication (Google, Azure AD, Okta)
* Approval workflows for critical changes
* Full audit logging
* On-premise and air-gapped deployment options
## What Can IncidentFox Do?
### Incident Investigation
When an incident occurs, IncidentFox automatically:
1. **Gathers Context** - Pulls logs, metrics, and recent changes from your observability stack
2. **Analyzes Root Cause** - Correlates data across services to identify the issue
3. **Provides Timeline** - Reconstructs what happened and when
4. **Suggests Fixes** - Recommends actionable remediation steps
```
@incidentfox investigate why the payments service is slow
```
### CI/CD Auto-Fix
When your CI pipeline fails, IncidentFox can:
1. **Detect Failures** - Monitors GitHub Actions, CodePipeline, and other CI systems
2. **Analyze Logs** - Reads test output and build errors
3. **Identify Root Cause** - Correlates failures with code changes in the PR
4. **Propose Fixes** - Suggests code changes to resolve the issue
### Proactive Monitoring
IncidentFox can monitor your systems and alert before issues escalate:
* **Anomaly Detection** - Prophet-based forecasting identifies unusual patterns
* **Correlation Analysis** - Links metrics across services to find relationships
* **Knowledge Base** - RAPTOR hierarchical retrieval learns from runbooks and past incidents
* **Alert Correlation** - Connects Prometheus, Alertmanager, and PagerDuty alerts
## Getting Started
Configure connections to your observability stack (Coralogix, Datadog, Grafana, etc.)
Connect IncidentFox to Slack, GitHub, or PagerDuty for triggering investigations
Customize agent prompts and enable/disable tools for your specific needs
Mention @incidentfox in Slack or trigger via your preferred integration
## Support
Need help? Contact us at [support@incidentfox.ai](mailto:support@incidentfox.ai)
# GitHub
Source: https://docs.incidentfox.ai/integrations/github
Set up IncidentFox GitHub integration for CI/CD analysis
## Overview
The GitHub integration enables IncidentFox to:
* Analyze CI/CD failures automatically
* Investigate code-related issues
* Correlate deployments with incidents
* Propose fixes for failing tests
## Prerequisites
* GitHub repository admin access
* IncidentFox account with GitHub integration enabled
* GitHub Personal Access Token (PAT)
## Setup
### Step 1: Generate GitHub Token
1. Go to GitHub **Settings** > **Developer settings** > **Personal access tokens**
2. Click **Generate new token (classic)**
3. Select scopes:
* `repo` - Full repository access
* `write:discussion` - Post comments
* `workflow` - Access GitHub Actions
4. Copy the generated token
Use a service account rather than personal account for production.
### Step 2: Configure Webhook
1. Go to your repository **Settings** > **Webhooks**
2. Click **Add webhook**
3. Configure:
* **Payload URL**: `https://api.incidentfox.ai/api/github/webhook`
* **Content type**: `application/json`
* **Secret**: Generate a random string
4. Select events:
* Issue comments
* Pull request review comments
* Check runs (for CI/CD monitoring)
5. Save
### Step 3: Add to IncidentFox
**Via Web UI:**
1. Go to **Team Console** > **Integrations**
2. Click **Add Integration** > **GitHub**
3. Enter:
* Personal Access Token
* Webhook Secret
* Default Organization
* Default Repository
4. Click **Test Connection**
5. Save
**Via Configuration:**
```json theme={null}
{
"tools": {
"github": {
"enabled": true,
"token": "vault://secrets/github-token",
"webhook_secret": "vault://secrets/github-webhook-secret",
"default_org": "acme-corp",
"default_repo": "main-app"
}
}
}
```
## Usage
### Trigger Investigation from PR
Comment on a Pull Request:
```
@incidentfox investigate why this test is failing
```
### Trigger from Issue
Comment on an Issue:
```
@incidentfox analyze the authentication changes in this PR
```
### Auto-Fix CI Failures
When a PR has failing checks:
```
@incidentfox fix the failing tests
```
IncidentFox will:
1. Analyze the CI logs
2. Identify the root cause
3. Propose a fix
4. Wait for approval before committing
## CI/CD Monitoring
### Automatic Investigation
Configure IncidentFox to automatically investigate CI failures:
```json theme={null}
{
"github": {
"auto_investigate_ci_failures": true,
"auto_investigate_repos": ["main-app", "api-service"],
"ci_failure_notification_channel": "#ci-failures"
}
}
```
### Supported CI Systems
| System | Status | Capabilities |
| ---------------- | ------ | ------------------------- |
| GitHub Actions | Full | Logs, status, artifacts |
| AWS CodePipeline | Full | Pipeline status, logs |
| Jenkins | Basic | Build status via webhooks |
| CircleCI | Basic | Status via webhooks |
## Auto-Fix Workflow
When IncidentFox identifies a fix:
CI failure detected via webhook
Agent analyzes logs and code changes
Identifies the specific breaking change
Posts proposed fix as a comment
Waits for user to type `fix` to approve
Pushes fix commit to the PR branch
### Example Fix Flow
**User comment:**
```
@incidentfox why is this PR failing?
```
**IncidentFox response:**
```
Investigation Complete
The Cypress test is failing because the API endpoint changed:
- Test expects: /api/data
- Backend returns: /api/records
Root Cause: Line 42 in src/api/index.js changed the endpoint path.
Proposed Fix:
- Update test file to use new endpoint path
Type `fix` to apply this change automatically.
```
**User response:**
```
fix
```
**IncidentFox:**
```
Fix applied! Created commit abc123.
Waiting for CI to complete...
✅ All checks passed!
```
## Tools Available
### `search_github_code`
Search code across repositories.
```
@incidentfox search for payment processing logic in the codebase
```
### `read_github_file`
Read specific file contents.
```
@incidentfox show me the contents of src/config/database.js
```
### `create_pull_request`
Create PRs (with approval).
```
@incidentfox create a PR with the fix
```
### `list_pull_requests`
List PRs in a repository.
```
@incidentfox show recent PRs for the api-service repo
```
### `get_github_actions_logs`
Fetch CI/CD logs.
```
@incidentfox get the logs from the failing GitHub Actions run
```
## Best Practices
**Start with read-only access** and enable write operations only when comfortable with the auto-fix capabilities.
1. **Use specific repos** - Don't enable for all repos initially
2. **Review fixes before applying** - Always verify proposed changes
3. **Set up notifications** - Route CI failures to appropriate channels
4. **Use branch protection** - Require review before merging auto-fixes
## Security Considerations
* Use fine-grained PATs when possible
* Store tokens in secrets manager
* Limit repository access scope
* Enable audit logging for all actions
* Require approval for write operations
## Troubleshooting
### Webhook Not Receiving
1. Check webhook URL is correct
2. Verify secret matches configuration
3. Check GitHub webhook delivery logs
4. Ensure network allows outbound to IncidentFox
### Bot Not Commenting
1. Verify PAT has `repo` scope
2. Check bot has write access to repo
3. Review webhook events enabled
## Next Steps
Auto-investigate alerts
See all GitHub tools
# Incident.io
Source: https://docs.incidentfox.ai/integrations/incident-io
Integrate IncidentFox with Incident.io for automated incident response
## Overview
Incident.io integration enables IncidentFox to:
* Automatically investigate when incidents are created
* Post findings to incident channels
* Enrich incident timelines with investigation data
* Correlate incidents with recent changes
* Access incident history and context
## Prerequisites
* Incident.io account with API access
* API key with read permissions
* Slack integration configured (for responses)
## Configuration
### Step 1: Create an Incident.io API Key
1. Go to your incident.io home dashboard
2. Click the settings gear icon at the bottom of the left navbar (next to your name)
3. Scroll down to the *Extend* section and click *API keys*
4. Click *Add New* (top right)
5. Click *View data...* (the first permission option)
6. Name your API key appropriately, scroll down, and click *Create*
7. Copy the API key
### Step 2: Connect to IncidentFox
See [Configuring Data Sources](/integrations/slack#configuring-data-sources) for general instructions on opening the configuration panel in Slack.
1. Open the IncidentFox app in Slack (click the bot's avatar → **Open App**)
2. Under **Available Integrations**, find Incident.io and click **Connect** (or **Edit** if already configured)
3. In the modal:
* Watch the **video walkthrough** for step-by-step guidance
* Paste your **API Key**
* Optionally, add **Custom Context** to help the AI understand your incident.io setup (e.g., team structure, service names, escalation patterns)
4. Click **Save**
### Custom Context for AI (Optional)
The **Context for AI** field lets you provide additional information that helps IncidentFox investigate more effectively. Examples:
* "Our critical services are `payments-api`, `checkout-service`, and `user-auth`"
* "High severity incidents automatically page the SRE on-call team"
* "We use incident.io custom fields for service ownership and deployment tracking"
This context is provided to the AI during investigations to help it understand your incident management workflow.
## Available Tools
Once configured, these tools become available:
### `get_incident_details`
Retrieve detailed information about a specific incident.
```
@incidentfox get details for incident INC-123
```
**Parameters:**
* `incident_id` - Incident identifier
* `include_timeline` - Include timeline events (optional)
### `list_recent_incidents`
Get a list of recent incidents with filtering options.
```
@incidentfox show recent incidents for the checkout service
```
**Parameters:**
* `service` - Filter by service (optional)
* `severity` - Filter by severity (optional)
* `status` - Active, resolved, all
* `time_range` - Time range to search
### `correlate_incidents`
Find similar or related incidents based on services, error patterns, or timing.
```
@incidentfox find similar incidents to the current database timeout issue
```
**Parameters:**
* `incident_id` - Reference incident
* `similarity_threshold` - Match confidence level
* `time_range` - How far back to search
## How It Works
```mermaid theme={null}
graph TD
A[Incident Created] --> B[IncidentFox Query]
B --> C[Incident.io API]
C --> D[Investigation]
D --> E[Findings]
E --> F[Slack Channel]
```
1. **Incident created** in Incident.io
2. **IncidentFox queries** incident details via API
3. **Investigation starts** with incident context
4. **Findings posted** to incident Slack channel
5. **Timeline optionally updated** with investigation summary
## Automatic Investigation
When an incident is created, IncidentFox:
1. **Extracts context** from incident title and description
2. **Identifies services** mentioned in the incident
3. **Queries data sources** for relevant logs/metrics
4. **Correlates with changes** in the last 4 hours
5. **Posts findings** to the incident channel
### Example
**Incident created:**
```
Title: High error rate on checkout service
Description: PagerDuty alert fired. Customers reporting failed checkouts.
```
**IncidentFox response (in incident channel):**
```
Investigation Started
Context: High error rate detected on checkout-service
Severity: High
Investigating...
---
Preliminary Findings:
Summary: Checkout service experiencing 503 errors due to
upstream dependency failure.
Root Cause (Confidence: 87%):
• Payment gateway returning timeout errors
• Started at 14:32 UTC
• Correlates with payment-gateway deploy at 14:30
Evidence:
• Error logs: "upstream connect error: connection timeout"
• 99.9th percentile latency: 30s (normal: 200ms)
• Payment gateway pod restarted 3 times
Recommended Actions:
1. Check payment-gateway pod logs
2. Consider rollback of payment-gateway deployment
3. Enable circuit breaker if not already active
Timeline:
• 14:30 - payment-gateway v2.1.0 deployed
• 14:32 - First timeout errors
• 14:35 - Error rate exceeded threshold
• 14:36 - PagerDuty alert fired
• 14:36 - This incident created
```
## Timeline Integration
IncidentFox can automatically add entries to your Incident.io timeline during investigations:
* **Investigation started** - When IncidentFox begins analyzing an incident
* **Root cause identified** - When high-confidence findings are detected
* **Investigation complete** - Final summary with recommendations
These timeline entries help maintain a chronological record of the investigation process alongside your manual incident updates.
## Severity Mapping
| Incident.io Severity | IncidentFox Priority |
| -------------------- | -------------------- |
| Critical | P0 |
| High | P1 |
| Medium | P2 |
| Low | P3 |
## Use Cases
### Historical Context During Incidents
```
@incidentfox check if we've had similar incidents to this checkout error
```
IncidentFox will:
* Search incident history for similar patterns
* Identify common root causes
* Reference previous resolutions
### Post-Incident Analysis
```
@incidentfox analyze incidents from the last quarter for the payments service
```
### Incident Correlation
```
@incidentfox check if the current incident correlates with recent deployments
```
## Best Practices
**Include service names and error patterns** in incident descriptions to help IncidentFox find relevant historical data.
1. **Use consistent service naming** across incident.io and your infrastructure
2. **Tag incidents properly** for better correlation
3. **Add PagerDuty context** when creating incidents
4. **Use structured descriptions** for better parsing
5. **Review similar incidents** before diving into investigation
## Security Considerations
### What IncidentFox Can Access
The API key with "View data" permissions grants these **read-only** capabilities:
| Permission | Purpose |
| -------------------- | ----------------------------------- |
| View incidents | Access incident details and history |
| View timelines | Read incident timeline events |
| View custom fields | Access service metadata |
| View users and teams | Understand on-call assignments |
### What IncidentFox Cannot Do
* Create, modify, or delete incidents
* Change incident status or severity
* Update postmortems or retrospectives
* Manage API keys or users
* Access or modify workflows
* Change team settings
### Best Practices
* **All permissions are read-only** - no write or management access
* **You control the key** - revoke anytime from your incident.io dashboard
* **No data storage** - IncidentFox queries on-demand; data stays in incident.io
* Store keys in your secrets manager
* Rotate keys periodically
* Monitor API usage for anomalies
### Revoking Access
To revoke IncidentFox's access at any time:
1. Go to your incident.io home dashboard
2. Click the settings gear icon at the bottom of the left navbar
3. Navigate to *Extend* > *API keys*
4. Find the IncidentFox key and click **Delete**
## Troubleshooting
### Connection Failed
**Symptom:** "Unable to connect to Incident.io API"
**Solutions:**
1. Verify API key is valid and not expired
2. Check that "View data" permission was granted
3. Ensure network allows outbound HTTPS to incident.io
### Missing Incident Data
**Symptom:** IncidentFox can't find incidents
**Solutions:**
1. Verify incident IDs are correct
2. Check time range - incidents may be outside the range
3. Ensure service names match those used in incident.io
### Rate Limiting
**Symptom:** "Rate limit exceeded" errors
**Solutions:**
1. Reduce query frequency
2. Use more specific filters (service, severity, time range)
3. Contact incident.io support to increase limits
## Next Steps
Connect PagerDuty
Configure Slack responses
# Kubernetes Agent
Source: https://docs.incidentfox.ai/integrations/kubernetes-agent
Connect your on-premise or private Kubernetes clusters to IncidentFox SaaS without firewall changes
## Overview
Connect your on-premise or private Kubernetes clusters to IncidentFox SaaS without firewall changes.
IncidentFox uses an **outbound agent pattern** to access your private Kubernetes clusters:
```
Your Kubernetes Cluster IncidentFox SaaS
==================== ================
┌──────────────────┐ ┌──────────────────┐
│ incidentfox- │ outbound │ K8s Gateway │
│ k8s-agent │───────────────>│ Service │
│ (Helm chart) │ HTTPS/SSE │ │
└────────┬─────────┘ └────────┬─────────┘
│ │
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ K8s API Server │ │ AI Agent │
│ (your cluster) │ │ (investigations) │
└──────────────────┘ └──────────────────┘
```
**Key benefits:**
* No inbound firewall rules needed
* Agent connects outbound to IncidentFox (port 443)
* You control RBAC permissions via Helm values
* Multiple clusters supported per team
## Prerequisites
Before you start:
* IncidentFox SaaS account with a team created
* Kubernetes cluster (v1.24+)
* `kubectl` configured and able to access your cluster
* `helm` v3.x installed
* Outbound HTTPS access to `ui.incidentfox.ai` (or your self-hosted gateway)
## Setup
1. Log in to the IncidentFox dashboard
2. Navigate to **Settings** → **Integrations** → **Kubernetes**
3. Click **"Add Cluster"**
4. Enter a **Cluster Name** (e.g., `prod-us-east-1`, `staging`)
5. Click **"Generate API Key"**
6. **Copy the API key** (starts with `ixfx_k8s_`) — you won't see it again!
The API key authenticates your agent with IncidentFox. Each cluster needs its own key.
```bash theme={null}
helm repo add incidentfox https://charts.incidentfox.ai
helm repo update
```
Create a namespace and install the agent:
```bash theme={null}
# Create namespace
kubectl create namespace incidentfox
# Install the agent
helm install incidentfox-agent incidentfox/incidentfox-k8s-agent \
--namespace incidentfox \
--set apiKey=ixfx_k8s_YOUR_API_KEY \
--set clusterName=prod-us-east-1
```
**Configuration options:**
| Parameter | Description | Default |
| -------------- | ---------------------------------------------- | --------------------------------------------- |
| `apiKey` | API key from Step 1 (required) | — |
| `clusterName` | Name shown in IncidentFox dashboard | — |
| `gatewayUrl` | IncidentFox gateway URL | `https://orchestrator.incidentfox.ai/gateway` |
| `replicaCount` | Number of agent replicas | `1` |
| `logLevel` | Logging verbosity (`DEBUG`, `INFO`, `WARNING`) | `INFO` |
1. Check agent pod is running:
```bash theme={null}
kubectl get pods -n incidentfox
```
You should see:
```
NAME READY STATUS RESTARTS AGE
incidentfox-agent-xxx-yyy 1/1 Running 0 30s
```
2. Check agent logs for successful connection:
```bash theme={null}
kubectl logs -n incidentfox -l app.kubernetes.io/name=incidentfox-k8s-agent
```
Look for:
```
{"event": "connected_to_gateway", "cluster_name": "prod-us-east-1"}
```
3. Verify in dashboard:
* Go to **Settings** → **Integrations** → **Kubernetes**
* Your cluster should show **Status: Connected**
## Usage
Once connected, ask IncidentFox about your cluster:
```
@incidentfox show me failing pods in prod-us-east-1
@incidentfox what's happening with deployment nginx in staging?
@incidentfox get logs from pod api-server-xxx in production
```
If you have multiple clusters, specify which one:
```
@incidentfox list pods in namespace payments on cluster prod-us-east-1
```
## RBAC Permissions
The agent uses a ClusterRole to access Kubernetes resources. By default, it has **read-only** access to:
| Resource | Permissions |
| ----------- | ---------------- |
| Pods | get, list, watch |
| Pod logs | get |
| Deployments | get, list, watch |
| ReplicaSets | get, list, watch |
| Services | get, list, watch |
| Nodes | get, list, watch |
| Events | get, list, watch |
| ConfigMaps | get, list, watch |
| Namespaces | get, list |
### Customizing RBAC
To restrict or expand permissions, use Helm values:
```yaml theme={null}
# values.yaml
rbac:
# Only allow access to specific namespaces
namespaceRestriction:
enabled: true
namespaces:
- production
- staging
# Add custom rules
additionalRules:
- apiGroups: ["apps"]
resources: ["statefulsets"]
verbs: ["get", "list", "watch"]
```
Apply with:
```bash theme={null}
helm upgrade incidentfox-agent incidentfox/incidentfox-k8s-agent \
--namespace incidentfox \
-f values.yaml
```
## Managing Multiple Clusters
Add multiple clusters by repeating the setup for each:
1. Generate a new API key for each cluster
2. Install the agent with a unique release name:
```bash theme={null}
# Production cluster
helm install incidentfox-agent-prod incidentfox/incidentfox-k8s-agent \
--namespace incidentfox \
--set apiKey=ixfx_k8s_PROD_KEY \
--set clusterName=prod-us-east-1
# Staging cluster (in a different cluster context)
helm install incidentfox-agent-staging incidentfox/incidentfox-k8s-agent \
--namespace incidentfox \
--set apiKey=ixfx_k8s_STAGING_KEY \
--set clusterName=staging
```
In the dashboard, you'll see all connected clusters and can query any of them.
## Revoking Access
To disconnect a cluster:
1. **Uninstall the agent:**
```bash theme={null}
helm uninstall incidentfox-agent -n incidentfox
```
2. **Revoke the API key** in the dashboard:
* Go to **Settings** → **Integrations** → **Kubernetes**
* Find the cluster and click **"Revoke"**
Revoking the key immediately disconnects the agent, even if it's still running.
## Troubleshooting
### Agent not connecting
**Check pod status:**
```bash theme={null}
kubectl describe pod -n incidentfox -l app.kubernetes.io/name=incidentfox-k8s-agent
```
**Common issues:**
| Symptom | Cause | Solution |
| --------------------------- | ---------------------- | ------------------------------- |
| `ImagePullBackOff` | Can't pull agent image | Check network/registry access |
| `CrashLoopBackOff` | Invalid API key | Verify API key in secret |
| `Running` but not connected | Network blocked | Allow outbound HTTPS to gateway |
**Check logs:**
```bash theme={null}
kubectl logs -n incidentfox -l app.kubernetes.io/name=incidentfox-k8s-agent --tail=100
```
### Connection drops frequently
The agent automatically reconnects with exponential backoff. Frequent disconnections may indicate:
* Unstable network connection
* Gateway maintenance (check status.incidentfox.ai)
* Resource constraints on the agent pod
**Check resource usage:**
```bash theme={null}
kubectl top pod -n incidentfox
```
**Increase resources if needed:**
```bash theme={null}
helm upgrade incidentfox-agent incidentfox/incidentfox-k8s-agent \
--namespace incidentfox \
--set resources.requests.memory=256Mi \
--set resources.limits.memory=512Mi
```
### Permission denied errors
If IncidentFox reports permission errors when querying resources:
1. Check the ClusterRole exists:
```bash theme={null}
kubectl get clusterrole incidentfox-agent
```
2. Verify ClusterRoleBinding:
```bash theme={null}
kubectl get clusterrolebinding incidentfox-agent
```
3. Test permissions manually:
```bash theme={null}
kubectl auth can-i list pods --as=system:serviceaccount:incidentfox:incidentfox-agent
```
## Security
| Concern | How we address it |
| -------------------------- | --------------------------------------------------------------------------- |
| **API key security** | Keys are hashed with SHA-256 + pepper; plaintext never stored |
| **Transport** | All traffic encrypted via TLS (HTTPS) |
| **Agent permissions** | You control RBAC; default is read-only |
| **Multi-tenant isolation** | Each team's clusters are isolated; agents can only access their team's data |
| **Audit logging** | All commands from IncidentFox are logged |
## Support
* **Email:** [support@incidentfox.ai](mailto:support@incidentfox.ai)
* **Documentation:** [docs.incidentfox.ai](https://docs.incidentfox.ai)
* **Status:** [status.incidentfox.ai](https://status.incidentfox.ai)
## Next Steps
Learn about Kubernetes tool capabilities
Set up Slack bot
Configure GitHub integration
Customize agent behavior
# Integrations Overview
Source: https://docs.incidentfox.ai/integrations/overview
Connect IncidentFox to your collaboration and incident management tools
## Overview
IncidentFox integrates with your existing collaboration and incident management tools to provide seamless investigation workflows.
## Trigger Integrations
These integrations allow you to invoke IncidentFox:
| Integration | Trigger Method | Use Case |
| -------------------------------------------------- | -------------------- | -------------------------------------- |
| [Slack](/integrations/slack) | @mention bot | General investigations, ad-hoc queries |
| [GitHub](/integrations/github) | @mention in PR/issue | CI/CD failures, code-related issues |
| [PagerDuty](/integrations/pagerduty) | Webhook on alert | Automatic incident investigation |
| [Incident.io](/integrations/incident-io) | Webhook on incident | Integrated incident response |
| [Kubernetes Agent](/integrations/kubernetes-agent) | Outbound agent | Private/on-prem cluster access |
| [REST API](/api-reference/introduction) | HTTP POST | Programmatic access, custom workflows |
| [Web UI](/integrations/web-ui) | Dashboard | Manual investigations, configuration |
## Alerting Integrations
These integrations provide alert context and correlation:
| Integration | Capabilities |
| --------------------------------------------------- | ---------------------------------------------- |
| [Prometheus/Alertmanager](/integrations/prometheus) | Alert rules, firing alerts, silence management |
| [Opsgenie](/integrations/opsgenie) | Alert management, escalation |
## Collaboration Integrations
| Integration | Capabilities |
| -------------------------------------- | ------------------------------------------- |
| [Slack](/integrations/slack) | Messages, channel history, threads, posting |
| [Microsoft Teams](/integrations/teams) | Messages, channels |
| [Linear](/integrations/linear) | Issue tracking, project management |
| [Jira](/integrations/jira) | Ticket creation, issue tracking |
## Integration Architecture
```mermaid theme={null}
graph TD
A[Slack Bot] --> G[Orchestrator]
B[GitHub Bot] --> G
C[PagerDuty Webhook] --> G
D[Incident.io Webhook] --> G
E[REST API] --> G
F[Web UI] --> G
G --> H[Agent Runtime]
H --> I[300+ Tools]
I --> J[Data Sources]
```
## Quick Setup
Most teams start with Slack for general use, then add GitHub for CI/CD workflows.
Follow the setup guide for each integration to install the necessary apps/webhooks.
Grant IncidentFox appropriate read permissions for your channels/repos.
Send a test message or trigger to verify the integration works.
## Integration Comparison
| Feature | Slack | GitHub | PagerDuty | Incident.io | Web UI | REST API |
| --------------------- | ----- | ------ | --------- | ----------- | ------ | -------- |
| Manual trigger | Yes | Yes | No | No | Yes | Yes |
| Auto-trigger on alert | No | No | Yes | Yes | No | Yes |
| Response in same tool | Yes | Yes | Via Slack | Via Slack | Yes | JSON |
| Rich formatting | Yes | Yes | Yes | Yes | Yes | N/A |
| Thread support | Yes | Yes | N/A | N/A | N/A | N/A |
| Interactive mode | Yes | No | No | No | Yes | Yes |
| Streaming responses | Yes | No | No | No | Yes | Yes |
## Recommended Setup
### For General SRE Teams
1. **Slack** - Primary interface for investigations
2. **PagerDuty** - Auto-investigate on alerts
3. **GitHub** - For deployment correlations
### For Development Teams
1. **Slack** - Quick queries and debugging
2. **GitHub** - CI/CD failure analysis
3. **PagerDuty** - Production alert context
### For Platform Teams
1. **Slack** - General investigations
2. **Incident.io** - Formal incident response
3. **All data sources** - Comprehensive access
## Next Steps
Set up Slack bot
Configure GitHub integration
Connect PagerDuty
Set up Incident.io
Connect private clusters
Connect Prometheus/Alertmanager
Use the dashboard
# PagerDuty
Source: https://docs.incidentfox.ai/integrations/pagerduty
Auto-investigate when PagerDuty alerts fire
## Overview
PagerDuty integration enables IncidentFox to:
* Automatically investigate when alerts trigger
* Post findings to configured Slack channels
* Provide context before the oncall engineer responds
* Correlate alerts with recent deployments
## Prerequisites
* PagerDuty account with admin access
* Webhook configuration permissions
* Slack integration configured (for responses)
## Setup
### Step 1: Create Generic Webhook
1. Log in to PagerDuty
2. Go to **Services** > Select your service
3. Click **Integrations** tab
4. Add **Generic Webhooks (v3)**
5. Configure:
* **URL**: `https://api.incidentfox.ai/api/pagerduty/webhook`
* **Events**: `incident.triggered`, `incident.acknowledged`
6. Copy the signing secret
7. Save
### Step 2: Add to IncidentFox
```json theme={null}
{
"integrations": {
"pagerduty": {
"enabled": true,
"webhook_secret": "vault://secrets/pagerduty-webhook-secret",
"auto_investigate": true,
"notification_channel": "#incidents"
}
}
}
```
### Configuration Options
| Option | Description | Default |
| ---------------------- | ----------------------------------- | -------- |
| `auto_investigate` | Auto-start investigation on trigger | `true` |
| `notification_channel` | Slack channel for findings | Required |
| `urgency_filter` | Only investigate high urgency | `all` |
| `service_filter` | List of services to investigate | All |
## How It Works
```mermaid theme={null}
graph LR
A[PagerDuty Alert] --> B[IncidentFox Agent]
B --> C[Slack Channel]
```
When a PagerDuty incident triggers:
1. **Webhook fires** to IncidentFox
2. **Agent extracts context** from alert details
3. **Investigation runs** against configured data sources
4. **Findings posted** to Slack before oncall responds
## Automatic Investigation
### Alert Context
IncidentFox extracts from the PagerDuty webhook:
* Service name
* Alert title/description
* Urgency level
* Custom details (if provided)
### Example Flow
**PagerDuty Alert:**
```
Service: checkout-api
Title: High Error Rate on checkout-api
Urgency: High
Details: Error rate exceeded 5% threshold
```
**IncidentFox Response (in #incidents):**
```
PagerDuty Alert Investigation
Service: checkout-api
Alert: High Error Rate
Urgency: High
Investigation Started...
---
Findings:
Summary: Checkout API experiencing elevated 5xx errors
due to database connection issues.
Root Cause (Confidence: 91%):
• RDS connection pool exhausted
• 100/100 connections in use
• New connections failing with timeout
Evidence:
• CloudWatch: RDS connections at max (100)
• Application logs: "connection pool exhausted"
• Error spike started 5 minutes ago
Recent Changes:
• checkout-api v2.3.0 deployed 15 minutes ago
• Change: Added new batch processing job
Recommendations:
1. Check if new batch job is holding connections
2. Consider increasing RDS max_connections
3. Rollback v2.3.0 if issue persists
Response Time: 23 seconds
```
## Service Configuration
Configure per-service investigation:
```json theme={null}
{
"integrations": {
"pagerduty": {
"services": {
"checkout-api": {
"investigation_prompt": "Focus on database and payment gateway issues",
"data_sources": ["coralogix", "rds", "grafana"],
"notification_channel": "#checkout-incidents"
},
"payments": {
"investigation_prompt": "Check PCI logs and card processor status",
"data_sources": ["coralogix", "cloudwatch"],
"notification_channel": "#payments-oncall"
}
}
}
}
}
```
## Urgency Filtering
Only investigate high urgency alerts:
```json theme={null}
{
"integrations": {
"pagerduty": {
"urgency_filter": "high"
}
}
}
```
## Enriching Alert Context
Add custom details to your PagerDuty alerts for better investigations:
```json theme={null}
{
"custom_details": {
"service": "checkout-api",
"environment": "production",
"namespace": "checkout",
"recent_deploy": "v2.3.0"
}
}
```
IncidentFox will use these details to target the investigation.
## Response Time
Typical investigation times:
| Alert Complexity | Response Time |
| ------------------- | ------------- |
| Single service | 15-30 seconds |
| Multi-service | 30-60 seconds |
| Complex correlation | 60-90 seconds |
IncidentFox aims to provide findings before the oncall engineer opens their laptop.
## Best Practices
1. **Add custom details** to alerts for targeted investigations
2. **Configure per-service** investigation prompts
3. **Use dedicated channels** per service/team
4. **Review investigation accuracy** to improve prompts
5. **Combine with Incident.io** for full incident workflow
## Troubleshooting
### Webhook Not Triggering
1. Check webhook URL is correct
2. Verify signing secret matches
3. Check PagerDuty webhook delivery logs
4. Ensure incident.triggered event is enabled
### Investigation Not Starting
1. Check service is not in filter exclude list
2. Verify urgency meets threshold
3. Review agent logs in Web UI
### Slow Investigations
1. Reduce number of data sources queried
2. Add more specific investigation prompts
3. Check data source connectivity
## Next Steps
Full incident workflow
Customize investigation behavior
# Slack
Source: https://docs.incidentfox.ai/integrations/slack
Set up the IncidentFox Slack bot for investigations
## Overview
The Slack bot is the primary interface for triggering IncidentFox investigations. Mention the bot in any channel to start an investigation.
## Prerequisites
* Slack workspace admin access
* IncidentFox account with Slack integration enabled
## Setup
### Step 1: Install the App
Your IncidentFox admin will provide an installation link:
```
https://app.incidentfox.ai/integrations/slack/install
```
Click the link and authorize the app for your workspace.
### Step 2: Configure Required Permissions
The app requests these permissions:
| Scope | Purpose |
| ------------------- | ---------------------------------- |
| `chat:write` | Post investigation results |
| `app_mentions:read` | Detect @incidentfox mentions |
| `channels:history` | Read context from channel |
| `groups:history` | Read context from private channels |
| `im:history` | Read direct message context |
| `reactions:write` | React to acknowledge messages |
### Step 3: Invite to Channels
Invite the bot to channels where you want to use it:
```
/invite @incidentfox
```
Add the bot to your incident channels so it's ready when you need it.
### Step 4: Test the Connection
Send a test message:
```
@incidentfox hello
```
The bot should respond with a confirmation.
## Usage
### Basic Investigation
```
@incidentfox investigate high latency in the payments service
```
### Check Specific Resources
```
@incidentfox check the status of cart pods in production namespace
```
### Query Logs
```
@incidentfox search for errors in checkout service logs from the last hour
```
### Get Help
```
@incidentfox help
```
## Response Format
When you trigger an investigation, IncidentFox:
1. Reacts with emoji to acknowledge
2. Creates a thread for the response
3. Posts structured findings:
* Summary
* Root cause
* Evidence
* Timeline
* Recommendations
### Example Response
```
Investigation: High latency in payments service
Summary: Payment service experiencing elevated latency due to
database connection pool exhaustion.
Root Cause:
• Description: RDS connection pool at maximum capacity
• Confidence: 92%
• Evidence:
- CloudWatch RDS connections at 100%
- Application logs show "connection timeout"
- Spike correlates with deploy at 14:32
Timeline:
• 14:32 - New deployment rolled out
• 14:35 - Connection count started increasing
• 14:42 - Connection pool exhausted
Recommendations:
1. Increase max_connections parameter
2. Review application pool settings
3. Consider rollback if issue persists
```
## Configuring Data Sources
Once the IncidentFox bot is installed, team members can configure data source integrations directly from Slack.
### Opening the Configuration Panel
There are two ways to access the configuration panel:
**Option 1: Welcome Message**
When IncidentFox joins a new channel, it posts a welcome message with a **Configure** button. Click this button to open the configuration panel.
**Option 2: App Home**
1. Click on the IncidentFox bot's avatar in any channel
2. Click **Open App**
3. You'll see:
* **Connected Integrations** - Data sources already configured (click **Edit** to modify)
* **Available Integrations** - Data sources you can add (click **Connect** to set up)
### Configuration Modal
When you click **Connect** or **Edit** for any integration, a modal appears with:
1. **Video Walkthrough** - Step-by-step guide for setting up the integration
2. **Setup Instructions** - Quick reference for creating API keys
3. **Configuration Fields** - API key, domain, and integration-specific settings
4. **Custom Context (Optional)** - Additional context to help the AI understand your setup
Credentials are encrypted and stored securely. You can revoke access at any time by deleting the integration.
See individual data source pages for specific setup instructions:
* [Coralogix](/data-sources/coralogix) - Log search, metrics, and alerts
* [Datadog](/data-sources/datadog) - Metrics, logs, and APM
* [AWS](/data-sources/aws) - CloudWatch and infrastructure
***
## Configuration
### Default Slack Channel
Set a default channel for notifications:
```json theme={null}
{
"slack_channel": "#incidents",
"slack_group_to_ping": "@oncall-platform"
}
```
### Bot Response Style
Configure in agent prompts how the bot communicates:
```
## Slack Communication Style
- Be concise and actionable
- Use bullet points for multiple items
- Include confidence levels
- Link to dashboards when relevant
- Use thread replies for detailed info
```
## Commands Reference
| Command | Description |
| ---------------------------------- | ----------------------- |
| `@incidentfox investigate ` | Full investigation |
| `@incidentfox check ` | Quick status check |
| `@incidentfox logs ` | Fetch recent logs |
| `@incidentfox metrics ` | Query metrics |
| `@incidentfox help` | Show available commands |
| `@incidentfox status` | Check agent status |
## Troubleshooting
### Bot Not Responding
1. Verify bot is invited to the channel
2. Check bot is online in Slack
3. Ensure mention includes `@incidentfox`
### Permission Errors
1. Re-authorize the app
2. Check channel permissions
3. Verify bot token is valid
### Slow Responses
1. Complex investigations take 30-60 seconds
2. Check data source connectivity
3. Review configured timeout settings
## Best Practices
1. **Use dedicated channels** for incidents
2. **Include context** in your request
3. **Use threads** to keep conversations organized
4. **React to helpful responses** to improve the model
5. **Share dashboards** the bot references
## Next Steps
Set up GitHub bot
Customize bot behavior
# Knowledge Base
Source: https://docs.incidentfox.ai/knowledge-base
RAPTOR hierarchical knowledge retrieval and pattern learning
## Overview
IncidentFox uses RAPTOR (Recursive Abstractive Processing for Tree-Organized Retrieval), a state-of-the-art hierarchical knowledge system based on ICLR 2024 research. This enables handling 100+ page runbooks without context loss.
## Why RAPTOR?
Traditional RAG (Retrieval Augmented Generation) struggles with:
| Challenge | Traditional RAG | RAPTOR |
| ---------------------- | --------------- | ------------------------ |
| Long documents | Loses context | Hierarchical abstraction |
| Complex relationships | Flat retrieval | Multi-level reasoning |
| Cross-document queries | Limited | Knowledge graph |
| Learning over time | Static | Pattern recording |
## Architecture
```mermaid theme={null}
graph TD
A[Documents] --> B[Chunking]
B --> C[Embedding]
C --> D[Clustering]
D --> E[Summarization]
E --> F[Tree Building]
F --> G[Retrieval]
H[Investigations] --> I[Pattern Extraction]
I --> J[Knowledge Graph]
J --> G
```
## Knowledge Types
RAPTOR organizes knowledge into abstraction levels:
| Level | Type | Examples |
| ----- | ---------- | ---------------------------------------- |
| L1 | Procedural | Step-by-step runbooks, remediation steps |
| L2 | Factual | Service configurations, thresholds, SLAs |
| L3 | Temporal | Past incidents, deployment history |
| L4 | Policy | Escalation rules, on-call rotations |
## Adding Knowledge
### Via API
```bash theme={null}
curl -X POST https://api.incidentfox.ai/api/v1/kb/teach \
-H "Authorization: Bearer $TEAM_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"content": "When the payments service shows high latency...",
"type": "runbook",
"service": "payments",
"tags": ["latency", "database"]
}'
```
### Via Slack
```
@incidentfox learn: When the checkout service returns 503 errors,
first check the Redis cluster health, then verify the connection pool settings.
```
### Via Web UI
1. Navigate to **Knowledge Base** > **Add Knowledge**
2. Paste or upload content
3. Tag with services and categories
4. Submit for processing
## Document Sources
IncidentFox can ingest knowledge from:
| Source | Method |
| -------------- | -------------------- |
| Confluence | API integration |
| Google Docs | OAuth connection |
| Notion | API integration |
| Markdown files | Direct upload |
| Past incidents | Automatic extraction |
### Confluence Integration
```json theme={null}
{
"knowledge_base": {
"sources": {
"confluence": {
"url": "https://your-company.atlassian.net",
"space_keys": ["SRE", "PLATFORM"],
"sync_interval": "1h"
}
}
}
}
```
## Knowledge Graph
Beyond tree structure, RAPTOR maintains a knowledge graph:
### Relationships
| Relationship | Description |
| ------------ | -------------------------- |
| `depends_on` | Service dependencies |
| `owned_by` | Team ownership |
| `expert_in` | Individual expertise |
| `related_to` | Related incidents/runbooks |
### Querying the Graph
```
@incidentfox who owns the payments service and what does it depend on?
```
## Learning from Investigations
IncidentFox automatically learns from successful investigations:
### Pattern Recording
After each investigation:
1. Extracts cause-solution pairs
2. Tags with services and symptoms
3. Stores in knowledge base
4. Increases confidence with repetition
### Example Pattern
```json theme={null}
{
"pattern_id": "pat_12345",
"symptoms": ["high latency", "connection timeout"],
"root_cause": "Database connection pool exhaustion",
"solution": "Increase max_connections and restart service",
"confidence": 0.85,
"occurrences": 5
}
```
### Finding Similar Investigations
```
@incidentfox have we seen this issue before?
```
IncidentFox searches for:
* Similar symptoms
* Same services
* Related error patterns
## Importance Scoring
RAPTOR uses 9+ signals to rank knowledge relevance:
| Signal | Weight | Description |
| ---------------- | ------- | ----------------------------- |
| Recency | High | Recently updated knowledge |
| Usage | High | Frequently referenced |
| Confidence | Medium | Verification status |
| Service match | High | Relevant to current service |
| Symptom match | High | Matches current symptoms |
| Author expertise | Medium | Written by domain expert |
| Freshness decay | Dynamic | Older knowledge decays |
| Contextual boost | Dynamic | Current investigation context |
| Feedback | Medium | User feedback signals |
## Configuration
### RAPTOR Settings
```json theme={null}
{
"knowledge_base": {
"raptor": {
"chunk_size": 512,
"cluster_threshold": 0.8,
"max_tree_depth": 4,
"embedding_model": "text-embedding-3-large"
}
}
}
```
### Retrieval Settings
```json theme={null}
{
"knowledge_base": {
"retrieval": {
"strategy": "hybrid", // "dense", "sparse", or "hybrid"
"reranker": "cohere",
"top_k": 10,
"min_relevance": 0.7
}
}
}
```
## API Endpoints
### Retrieve Knowledge
```bash theme={null}
POST /api/v1/kb/retrieve
{
"query": "how to handle checkout service outage",
"service": "checkout",
"top_k": 5
}
```
### Get Answer with Sources
```bash theme={null}
POST /api/v1/kb/answer
{
"question": "What is the escalation path for P1 incidents?",
"include_sources": true
}
```
### Provide Feedback
```bash theme={null}
POST /api/v1/kb/feedback
{
"query_id": "q_12345",
"helpful": true,
"comment": "This runbook was exactly what I needed"
}
```
### Tree Statistics
```bash theme={null}
GET /api/v1/kb/tree/stats
```
Returns:
* Total documents
* Tree depth
* Node counts by level
* Last sync time
## Best Practices
### Document Quality
* Keep runbooks up to date
* Include specific commands and thresholds
* Add examples and expected outcomes
* Tag with relevant services
### Feedback Loop
* Provide feedback on retrieved knowledge
* Flag outdated information
* Suggest improvements
### Service Tagging
Tag all knowledge with:
* Service name
* Environment (prod, staging)
* Category (runbook, alert, architecture)
## Troubleshooting
### Knowledge Not Retrieved
1. Check document is indexed: `GET /api/v1/kb/status`
2. Verify tagging and metadata
3. Check relevance threshold settings
### Stale Knowledge
1. Set up automatic sync from sources
2. Configure freshness decay
3. Regularly review and update
## Next Steps
See RAPTOR in the full architecture
Configure knowledge settings
# Quick Start
Source: https://docs.incidentfox.ai/quickstart
Get IncidentFox investigating incidents in minutes
## Overview
This guide walks you through setting up IncidentFox for your team. By the end, you'll have an AI SRE agent ready to investigate incidents from Slack.
IncidentFox is deployed as a managed service. Contact your account team for access credentials and your team token.
## Step 1: Get Your Credentials
After onboarding, you'll receive:
* **Team Token** - Used to authenticate API requests
* **Web UI Access** - Dashboard to configure agents and view investigation history
* **Slack App** - Bot to install in your workspace
Your team token follows the format `tokid.toksecret`. Keep it secure and never commit to version control.
## Step 2: Install the Slack Bot
The Slack bot is the primary interface for triggering investigations.
Your IncidentFox admin will provide an installation link. Click it and authorize the app for your Slack workspace.
Invite `@incidentfox` to channels where you want to trigger investigations:
```
/invite @incidentfox
```
Send a test message:
```
@incidentfox hello
```
The bot should respond confirming it's connected.
## Step 3: Configure Data Sources
Connect IncidentFox to your observability stack to enable investigations.
### Via Web UI
1. Log in to your IncidentFox dashboard
2. Navigate to **Team Console** > **Integrations**
3. Click **Add Integration** and select your data source
4. Enter the required credentials
### Common Data Sources
| Platform | Required Credentials |
| --------- | -------------------------------------- |
| Coralogix | API Key, Domain |
| Snowflake | Account, Username, Password, Warehouse |
| AWS | Access Key, Secret Key, Region |
| Datadog | API Key, Application Key |
| Grafana | URL, API Key |
| GitHub | Personal Access Token |
See the [Data Sources](/data-sources/overview) section for detailed setup instructions for each platform.
## Step 4: Enable Tools
IncidentFox comes with 300+ built-in tools. Enable the ones relevant to your stack.
In the Web UI:
1. Go to **Team Console** > **Tools**
2. Toggle on the tools you need
3. Configure any tool-specific settings
Example configuration:
```json theme={null}
{
"tools": {
"kubernetes": {
"enabled": true,
"kubeconfig_path": "~/.kube/config"
},
"aws": {
"enabled": true,
"region": "us-west-2"
},
"coralogix": {
"enabled": true,
"api_key": "vault://secrets/coralogix"
}
}
}
```
## Step 5: Start Investigating
You're ready to go! Try these commands in Slack:
### Basic Investigation
```
@incidentfox investigate high latency in the payments service
```
### Check Pod Status
```
@incidentfox check the status of cart pods in production
```
### Analyze CI Failure
```
@incidentfox why did the build fail on PR #123?
```
### Query Logs
```
@incidentfox search for errors in the checkout service logs from the last hour
```
## What Happens During an Investigation
When you trigger an investigation, IncidentFox:
1. **Acknowledges** - Reacts to your message to confirm it's working
2. **Plans** - The Planner agent creates an investigation strategy
3. **Gathers Data** - Pulls logs, metrics, and events from your data sources
4. **Analyzes** - Correlates data to identify root cause
5. **Reports** - Posts findings back to the Slack thread
## Example Investigation Output
```json theme={null}
{
"summary": "Payment service experiencing elevated latency due to database connection pool exhaustion",
"root_cause": {
"description": "RDS connection pool at maximum capacity (100/100 connections)",
"confidence": 92,
"evidence": [
"CloudWatch RDS connections metric at 100%",
"Application logs show 'connection timeout' errors",
"Spike correlates with deployment at 14:32 UTC"
]
},
"timeline": [
"14:32 - New deployment rolled out",
"14:35 - Connection count started increasing",
"14:42 - Connection pool exhausted",
"14:43 - Latency alerts fired"
],
"affected_systems": ["payment-service", "checkout-service", "RDS primary"],
"recommendations": [
"Increase RDS max_connections parameter",
"Review connection pool settings in application config",
"Consider rolling back deployment if issue persists"
]
}
```
## Next Steps
Customize agent behavior with system prompts
Connect all your observability tools
Enable CI/CD auto-fix capabilities
See all 300+ available tools
# Security
Source: https://docs.incidentfox.ai/security
Security architecture, compliance, and best practices
## Overview
IncidentFox is built with enterprise security as a core principle. This document covers the security architecture, compliance certifications, and best practices for secure deployment.
## Security Architecture
```mermaid theme={null}
graph TD
subgraph "External"
A[User Request]
end
subgraph "IncidentFox"
B[API Gateway / ALB]
C[Orchestrator]
D[Agent Runtime]
E[Envoy Proxy]
F[Credential Resolver]
end
subgraph "Secrets"
G[AWS Secrets Manager]
H[HashiCorp Vault]
end
subgraph "Data Sources"
I[External APIs]
end
A --> B
B --> C
C --> D
D --> E
E --> F
F --> G
F --> H
E --> I
```
## Credentials Proxy
**Secrets never touch the agent.** IncidentFox uses an Envoy-based credentials proxy:
1. Agent makes API call through Envoy proxy
2. Envoy intercepts the request
3. Credential Resolver fetches secrets from vault
4. Envoy injects credentials at request time
5. Request is forwarded to external API
6. Secrets are never stored in agent memory
### Benefits
| Traditional Approach | IncidentFox Approach |
| ----------------------- | ---------------------------- |
| Agent stores secrets | Secrets in proxy only |
| Risk of memory exposure | Isolated credential handling |
| Static credentials | Dynamic credential injection |
| Audit gaps | Full audit trail |
## Claude Sandbox Isolation
The Claude SDK SRE Agent runs in isolated Kubernetes sandboxes:
### gVisor Isolation
* User-space kernel intercepts all syscalls
* Reduced kernel attack surface
* Container-to-host isolation
### Network Policies
```yaml theme={null}
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: agent-sandbox
spec:
podSelector:
matchLabels:
app: sre-agent
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
name: incidentfox
- ports:
- port: 443 # HTTPS only
```
### Resource Limits
* CPU: Bounded to prevent runaway processes
* Memory: Capped to prevent OOM attacks
* Time: Maximum investigation duration
* Ephemeral: Sandbox destroyed after use
## Authentication
### Token Types
| Type | Format | Scope | Expiration |
| ------------ | ----------------------------- | ------------ | ------------ |
| Global Admin | `ADMIN_TOKEN` env var | Full access | Never |
| Org Admin | `{org_id}.{random}` | Organization | Configurable |
| Team Token | `{org_id}.{team_id}.{random}` | Team only | Configurable |
| OIDC JWT | Standard JWT | User session | Short-lived |
### SSO/OIDC Support
Supported identity providers:
* Google Workspace
* Azure AD / Entra ID
* Okta
* Generic OIDC
### Configuration
```json theme={null}
{
"auth": {
"oidc": {
"issuer": "https://accounts.google.com",
"client_id": "your-client-id",
"allowed_domains": ["your-company.com"]
}
}
}
```
## Authorization (RBAC)
### Roles
| Role | Permissions |
| --------- | ------------------------------------- |
| Viewer | Read investigations, view dashboards |
| Operator | Trigger investigations, view all data |
| Admin | Configure tools, manage team settings |
| Org Admin | Manage teams, configure org settings |
### Tool-Level Permissions
Restrict access to sensitive tools:
```json theme={null}
{
"tools": {
"docker_exec": {
"enabled": true,
"allowed_roles": ["admin"],
"require_approval": true
}
}
}
```
## Approval Workflows
For high-risk operations, require approval:
```json theme={null}
{
"approval_workflows": {
"enabled": true,
"actions": {
"pod_restart": {
"required_approvers": 1,
"timeout_minutes": 30,
"notify_channel": "#sre-approvals"
},
"scale_deployment": {
"required_approvers": 2,
"timeout_minutes": 15
}
}
}
}
```
### Approval Flow
1. Agent proposes action
2. Notification sent to approvers
3. Approver reviews and approves/denies
4. Action executed or cancelled
## Audit Logging
All operations are logged:
### Event Types
| Event | Logged Data |
| -------------------------- | ------------------------------------ |
| Investigation started | User, query, timestamp |
| Tool executed | Tool name, parameters, result status |
| Data accessed | Data source, query, row count |
| Configuration changed | Old value, new value, user |
| Approval requested/granted | Action, approver, decision |
### Log Format
```json theme={null}
{
"timestamp": "2024-01-15T14:30:00Z",
"event_type": "tool_executed",
"user_id": "user@company.com",
"team_id": "team_123",
"tool": "get_pod_logs",
"parameters": {
"namespace": "production",
"pod": "api-server-xyz"
},
"duration_ms": 1234,
"status": "success"
}
```
### Log Destinations
* CloudWatch Logs
* Datadog
* Splunk
* Custom webhook
## Compliance
### SOC 2 Type II
IncidentFox maintains SOC 2 Type II certification:
| Control | Implementation |
| ----------------- | ------------------------- |
| Access Control | RBAC, SSO, MFA |
| Encryption | TLS 1.3, AES-256 at rest |
| Logging | Comprehensive audit trail |
| Monitoring | Real-time alerting |
| Incident Response | Documented procedures |
### Data Handling
| Data Type | Handling |
| --------------------- | --------------------------- |
| Investigation queries | Logged, retained 90 days |
| Tool results | Not stored (passed through) |
| Credentials | Never stored in agent |
| Audit logs | Retained per policy |
## Deployment Security
### Self-Hosted
For maximum control:
* Deploy in your VPC
* Use your secrets manager
* Control all network egress
* Manage your own keys
### Air-Gapped
For highly restricted environments:
* No external network access
* Local model inference
* Internal secrets management
* Manual updates
## Best Practices
### Credential Management
1. Use vault references, never plain text
2. Rotate credentials regularly
3. Use service accounts with minimal permissions
4. Enable audit logging for secret access
### Network Security
1. Use private endpoints where possible
2. Enable VPC peering for cloud services
3. Restrict agent egress to necessary destinations
4. Use TLS for all communications
### Access Control
1. Enable SSO for all users
2. Use team-scoped tokens
3. Require MFA for admin access
4. Regular access reviews
### Monitoring
1. Alert on authentication failures
2. Monitor for unusual tool usage
3. Track investigation patterns
4. Review audit logs regularly
## Incident Response
### Security Incidents
If you discover a security issue:
1. Email [security@incidentfox.ai](mailto:security@incidentfox.ai)
2. Do not disclose publicly
3. We will respond within 24 hours
### Vulnerability Disclosure
We follow responsible disclosure:
* 90-day disclosure timeline
* Credit for reporters
* Bug bounty program available
## Next Steps
Configure security settings
API authentication details
# Anomaly Detection Tools
Source: https://docs.incidentfox.ai/tools/anomaly-detection
AI-powered anomaly detection, forecasting, and correlation analysis
## Overview
IncidentFox provides 8 AI/ML-powered tools for anomaly detection, forecasting, and correlation analysis. These tools use statistical methods and Facebook Prophet for sophisticated time series analysis.
## Tools Available
| Tool | Description |
| ----------------------------- | ---------------------------------------- |
| `detect_anomalies` | Z-score statistical anomaly detection |
| `prophet_detect_anomalies` | Prophet-based seasonal anomaly detection |
| `find_change_point` | Identify when metrics behavior changed |
| `correlate_metrics` | Find relationships between metrics |
| `forecast_metric` | Capacity planning forecasts |
| `prophet_forecast` | Prophet-based seasonal forecasting |
| `prophet_decompose` | Decompose trend, seasonality, residuals |
| `analyze_metric_distribution` | Statistical distribution analysis |
## detect\_anomalies
Z-score based anomaly detection for quick analysis:
```
@incidentfox detect anomalies in the payments service latency
```
**How it works:**
1. Calculates mean and standard deviation
2. Identifies points > N standard deviations from mean
3. Returns anomalous time periods
**Configuration:**
```json theme={null}
{
"anomaly_detection": {
"z_score_threshold": 3.0,
"min_data_points": 100
}
}
```
## prophet\_detect\_anomalies
Seasonal anomaly detection using Facebook Prophet:
```
@incidentfox use prophet to detect anomalies in CPU usage accounting for daily patterns
```
**Advantages over Z-score:**
* Accounts for seasonality (daily, weekly patterns)
* Handles trends
* Provides uncertainty intervals
* Better for business metrics with patterns
**Returns:**
* Anomalous periods with confidence scores
* Expected vs actual values
* Uncertainty bounds
## find\_change\_point
Identify when metric behavior fundamentally changed:
```
@incidentfox when did the error rate behavior change?
```
**Use cases:**
* Identify incident start time
* Detect deployment impacts
* Find gradual degradation onset
**Returns:**
```json theme={null}
{
"change_points": [
{
"timestamp": "2024-01-15T14:32:00Z",
"confidence": 0.95,
"metric_before": 0.01,
"metric_after": 0.15,
"description": "Error rate increased 15x"
}
]
}
```
## correlate\_metrics
Find relationships between metrics:
```
@incidentfox correlate latency with CPU usage and database connections
```
**Analysis:**
* Pearson correlation coefficient
* Lag correlation (time-shifted relationships)
* Causal direction hints
**Returns:**
```json theme={null}
{
"correlations": [
{
"metric_a": "latency_p99",
"metric_b": "db_connections",
"correlation": 0.87,
"lag_seconds": 30,
"description": "DB connections lead latency by 30s"
}
]
}
```
## forecast\_metric
Linear forecasting for capacity planning:
```
@incidentfox forecast disk usage for the next 7 days
```
**Returns:**
* Predicted values with confidence intervals
* Time to threshold (e.g., "disk full in 5 days")
* Trend direction and rate
## prophet\_forecast
Sophisticated seasonal forecasting:
```
@incidentfox use prophet to forecast request volume for next week
```
**Capabilities:**
* Daily and weekly seasonality
* Holiday effects
* Trend changes
* Uncertainty quantification
## prophet\_decompose
Decompose time series into components:
```
@incidentfox decompose the traffic pattern to show trend and seasonality
```
**Returns:**
* Trend component
* Seasonal component (daily, weekly)
* Residual (unexplained variation)
**Use cases:**
* Understand underlying patterns
* Separate signal from noise
* Identify true anomalies vs seasonal variation
## analyze\_metric\_distribution
Statistical distribution analysis:
```
@incidentfox analyze the latency distribution for the API service
```
**Returns:**
* Percentiles (p50, p90, p95, p99)
* Mean, median, mode
* Standard deviation
* Distribution shape (normal, skewed, bimodal)
## Configuration
### Global Settings
```json theme={null}
{
"anomaly_detection": {
"default_lookback": "24h",
"z_score_threshold": 3.0,
"prophet_enabled": true,
"seasonality_mode": "multiplicative"
}
}
```
### Prophet Settings
```json theme={null}
{
"prophet": {
"daily_seasonality": true,
"weekly_seasonality": true,
"yearly_seasonality": false,
"changepoint_prior_scale": 0.05
}
}
```
## Use Cases
### Incident Investigation
1. Use `find_change_point` to identify when issue started
2. Apply `detect_anomalies` to find related metric spikes
3. Use `correlate_metrics` to identify root cause
### Capacity Planning
1. Use `prophet_forecast` to predict growth
2. Identify time to capacity threshold
3. Plan scaling actions
### Pattern Understanding
1. Use `prophet_decompose` to understand patterns
2. Separate business cycles from anomalies
3. Set appropriate alerting thresholds
## Best Practices
### Data Quality
* Ensure sufficient historical data (minimum 2 weeks for Prophet)
* Handle missing data points
* Remove known maintenance windows
### Threshold Selection
| Use Case | Z-Score Threshold |
| --------------- | ----------------- |
| Strict alerting | 2.0 |
| Normal alerting | 3.0 |
| Loose alerting | 4.0 |
### Seasonality
Enable appropriate seasonality for your metrics:
* API traffic: daily + weekly
* Batch jobs: specific schedule
* Infrastructure: often no seasonality
## Next Steps
Combine with log analysis
Query Prometheus metrics
# AWS Tools
Source: https://docs.incidentfox.ai/tools/aws
Tools for AWS infrastructure troubleshooting
## Overview
The AWS tools enable IncidentFox to access CloudWatch, EC2, RDS, Lambda, ECS, and CodePipeline.
## Configuration
```json theme={null}
{
"tools": {
"aws": {
"enabled": true,
"region": "us-west-2",
"assume_role": "arn:aws:iam::123456789:role/incidentfox"
}
}
}
```
## Available Tools
### `get_cloudwatch_logs`
Fetch logs from CloudWatch Log Groups.
**Parameters:**
| Parameter | Type | Required | Description |
| ---------------- | ------ | -------- | ----------------- |
| `log_group` | string | Yes | Log group name |
| `filter_pattern` | string | No | CloudWatch filter |
| `start_time` | string | No | Start time |
| `end_time` | string | No | End time |
| `limit` | int | No | Max events |
**Example:**
```
@incidentfox get cloudwatch logs for /aws/lambda/payments with ERROR filter
```
### `query_cloudwatch_insights`
Run CloudWatch Logs Insights queries.
**Parameters:**
| Parameter | Type | Required | Description |
| ------------ | ------ | -------- | ------------------- |
| `log_groups` | list | Yes | Log groups to query |
| `query` | string | Yes | Insights query |
| `start_time` | string | No | Start time |
| `end_time` | string | No | End time |
**Example:**
```
@incidentfox run insights query to find top errors by count in /aws/ecs/checkout
```
**Query Example:**
```sql theme={null}
fields @timestamp, @message
| filter @message like /ERROR/
| stats count(*) by bin(1h)
```
### `get_cloudwatch_metrics`
Query CloudWatch metrics.
**Parameters:**
| Parameter | Type | Required | Description |
| ------------- | ------ | -------- | ----------------- |
| `namespace` | string | Yes | Metric namespace |
| `metric_name` | string | Yes | Metric name |
| `dimensions` | dict | No | Dimension filters |
| `statistic` | string | No | Average, Sum, Max |
| `period` | int | No | Period in seconds |
**Example:**
```
@incidentfox get CPUUtilization metric for EC2 instance i-abc123
```
### `describe_ec2_instance`
Get EC2 instance details.
**Parameters:**
| Parameter | Type | Required | Description |
| ------------- | ------ | -------- | --------------- |
| `instance_id` | string | Yes | EC2 instance ID |
**Response:**
```json theme={null}
{
"instance_id": "i-abc123",
"state": "running",
"type": "t3.large",
"launch_time": "2024-01-10T08:00:00Z",
"private_ip": "10.0.1.100",
"security_groups": ["sg-web", "sg-internal"]
}
```
### `describe_lambda_function`
Get Lambda function configuration.
**Parameters:**
| Parameter | Type | Required | Description |
| --------------- | ------ | -------- | -------------------- |
| `function_name` | string | Yes | Lambda function name |
**Response:**
```json theme={null}
{
"function_name": "payment-processor",
"runtime": "python3.11",
"memory": 256,
"timeout": 30,
"last_modified": "2024-01-15T10:00:00Z",
"code_size": 1024000
}
```
### `get_rds_instance_status`
Check RDS database status.
**Parameters:**
| Parameter | Type | Required | Description |
| --------------- | ------ | -------- | --------------- |
| `db_identifier` | string | Yes | RDS instance ID |
**Response:**
```json theme={null}
{
"identifier": "prod-db",
"status": "available",
"engine": "postgres",
"version": "14.10",
"endpoint": "prod-db.xxx.us-west-2.rds.amazonaws.com",
"connections": 45,
"storage_used": "100GB"
}
```
### `list_ecs_tasks`
List ECS tasks in a cluster.
**Parameters:**
| Parameter | Type | Required | Description |
| --------- | ------ | -------- | ---------------- |
| `cluster` | string | Yes | ECS cluster name |
| `service` | string | No | Service name |
| `status` | string | No | RUNNING, STOPPED |
### `describe_codepipeline`
Get CodePipeline execution status.
**Parameters:**
| Parameter | Type | Required | Description |
| --------------- | ------ | -------- | ------------- |
| `pipeline_name` | string | Yes | Pipeline name |
**Response:**
```json theme={null}
{
"pipeline": "main-deploy",
"status": "InProgress",
"stages": [
{"name": "Source", "status": "Succeeded"},
{"name": "Build", "status": "Succeeded"},
{"name": "Deploy", "status": "InProgress"}
],
"last_execution": "2024-01-15T14:30:00Z"
}
```
## Use Cases
### Lambda Error Investigation
```
@incidentfox investigate errors in payment-processor Lambda
```
IncidentFox will:
1. `describe_lambda_function` - Check config
2. `get_cloudwatch_logs` - Recent errors
3. `get_cloudwatch_metrics` - Error rate, duration
### RDS Performance Issues
```
@incidentfox check RDS performance for prod-db
```
IncidentFox will:
1. `get_rds_instance_status` - Instance status
2. `get_cloudwatch_metrics` - CPU, connections, IOPS
3. Query Performance Insights if available
### Deployment Tracking
```
@incidentfox check recent CodePipeline deployments
```
## Required IAM Permissions
See [AWS Data Source](/data-sources/aws) for full IAM policy.
## Next Steps
Metrics and logging tools
Full AWS configuration
# Custom MCP Tools
Source: https://docs.incidentfox.ai/tools/custom-mcp
Extend IncidentFox with your own tools via Model Context Protocol
## Overview
The Model Context Protocol (MCP) allows you to add custom tools to IncidentFox. This enables integration with internal systems, custom runbooks, and proprietary data sources.
## What is MCP?
MCP is an open protocol that standardizes how AI agents access external tools and data sources. IncidentFox supports MCP servers, allowing you to:
* Add tools for internal APIs
* Integrate with custom databases
* Access proprietary monitoring systems
* Connect to internal runbook systems
## Architecture
```mermaid theme={null}
graph TD
A[IncidentFox Agent] --> B[MCP Server
Your Custom]
B --> C[Your Internal
Systems]
```
## Configuration
### Adding an MCP Server
```json theme={null}
{
"mcp_servers": [
{
"name": "internal-tools",
"url": "https://mcp.internal.company.com",
"auth": {
"type": "bearer",
"token": "vault://secrets/mcp-internal-token"
}
},
{
"name": "runbooks",
"url": "https://runbooks-mcp.company.com",
"auth": {
"type": "api_key",
"header": "X-API-Key",
"key": "vault://secrets/runbooks-api-key"
}
}
]
}
```
### Configuration Options
| Option | Type | Required | Description |
| --------- | ------ | -------- | ------------------------- |
| `name` | string | Yes | Unique server name |
| `url` | string | Yes | MCP server URL |
| `auth` | object | No | Authentication config |
| `timeout` | int | No | Request timeout (seconds) |
| `enabled` | bool | No | Enable/disable server |
## Building an MCP Server
### Server Requirements
Your MCP server must implement:
1. **Tool Discovery** - `GET /tools` returns available tools
2. **Tool Execution** - `POST /tools/{name}` executes a tool
3. **Health Check** - `GET /health` for monitoring
### Example Server (Python)
```python theme={null}
from fastapi import FastAPI
from pydantic import BaseModel
app = FastAPI()
class ToolDefinition(BaseModel):
name: str
description: str
parameters: dict
class ToolRequest(BaseModel):
parameters: dict
@app.get("/tools")
def list_tools():
return [
{
"name": "search_runbooks",
"description": "Search internal runbooks for troubleshooting steps",
"parameters": {
"type": "object",
"properties": {
"query": {"type": "string", "description": "Search query"},
"service": {"type": "string", "description": "Service filter"}
},
"required": ["query"]
}
},
{
"name": "get_service_owners",
"description": "Get the team and oncall for a service",
"parameters": {
"type": "object",
"properties": {
"service": {"type": "string", "description": "Service name"}
},
"required": ["service"]
}
}
]
@app.post("/tools/search_runbooks")
def search_runbooks(request: ToolRequest):
query = request.parameters.get("query")
service = request.parameters.get("service")
# Your implementation here
results = internal_search(query, service)
return {"results": results}
@app.post("/tools/get_service_owners")
def get_service_owners(request: ToolRequest):
service = request.parameters["service"]
# Your implementation here
owners = get_owners_from_db(service)
return {"team": owners["team"], "oncall": owners["oncall"]}
@app.get("/health")
def health():
return {"status": "healthy"}
```
### Tool Definition Schema
```json theme={null}
{
"name": "tool_name",
"description": "What the tool does",
"parameters": {
"type": "object",
"properties": {
"param1": {
"type": "string",
"description": "Parameter description"
}
},
"required": ["param1"]
}
}
```
## Use Cases
### Internal Runbook Search
Create a tool that searches your internal knowledge base:
```json theme={null}
{
"name": "search_runbooks",
"description": "Search internal runbooks for incident response procedures"
}
```
**Usage:**
```
@incidentfox search runbooks for database failover procedure
```
### Service Catalog
Create a tool that queries your service catalog:
```json theme={null}
{
"name": "get_service_info",
"description": "Get service metadata including team, oncall, dependencies"
}
```
**Usage:**
```
@incidentfox who owns the payments service and what are its dependencies?
```
### Custom Metrics
Create a tool that queries proprietary metrics systems:
```json theme={null}
{
"name": "query_custom_metrics",
"description": "Query internal metrics platform"
}
```
### Approval Systems
Create a tool that interacts with your change management system:
```json theme={null}
{
"name": "check_recent_changes",
"description": "Check recent approved changes in ServiceNow"
}
```
## Equipping Tools to Agents
After configuring an MCP server, equip its tools to agents:
```json theme={null}
{
"agents": {
"investigation_agent": {
"enable_extra_tools": [
"internal-tools:search_runbooks",
"internal-tools:get_service_info",
"runbooks:get_playbook"
]
}
}
}
```
Tool names use the format: `{mcp_server_name}:{tool_name}`
## Security Considerations
MCP servers have direct access to your internal systems. Ensure proper security.
1. **Authentication** - Always use authentication
2. **Network Security** - Run MCP servers in private networks
3. **Input Validation** - Validate all parameters
4. **Rate Limiting** - Implement rate limits
5. **Audit Logging** - Log all tool invocations
6. **Least Privilege** - Only expose necessary functionality
## Monitoring MCP Servers
Track MCP tool usage in IncidentFox:
* Tool invocation counts
* Latency by tool
* Error rates
* Most used tools
View in **Team Console** > **Agent Runs**.
## Troubleshooting
### Connection Failed
1. Verify URL is correct
2. Check network connectivity
3. Verify authentication credentials
4. Check server health endpoint
### Tool Not Found
1. Verify tool is returned by `/tools`
2. Check tool name matches exactly
3. Ensure MCP server is enabled
### Execution Errors
1. Check parameter schema matches
2. Review server logs
3. Verify internal system connectivity
## Next Steps
Configure MCP servers
See all available tools
# GitHub Tools
Source: https://docs.incidentfox.ai/tools/github
Tools for code search, PRs, issues, and GitHub Actions
## Overview
GitHub tools enable IncidentFox to search code, analyze PRs, and interact with CI/CD workflows.
## Configuration
```json theme={null}
{
"tools": {
"github": {
"enabled": true,
"token": "vault://secrets/github-token",
"default_org": "acme-corp"
}
}
}
```
## Available Tools
### Code Tools
#### `search_github_code`
Search code across repositories.
**Parameters:**
| Parameter | Type | Required | Description |
| ---------- | ------ | -------- | ----------------- |
| `query` | string | Yes | Search query |
| `repo` | string | No | Repository filter |
| `language` | string | No | Language filter |
**Example:**
```
@incidentfox search for payment processing error handling
```
#### `read_github_file`
Read file contents from a repository.
**Parameters:**
| Parameter | Type | Required | Description |
| --------- | ------ | -------- | --------------- |
| `repo` | string | Yes | Repository name |
| `path` | string | Yes | File path |
| `ref` | string | No | Branch/commit |
### PR Tools
#### `list_pull_requests`
List PRs in a repository.
**Parameters:**
| Parameter | Type | Required | Description |
| --------- | ------ | -------- | ----------------- |
| `repo` | string | Yes | Repository |
| `state` | string | No | open, closed, all |
| `base` | string | No | Base branch |
#### `get_pull_request`
Get PR details.
**Parameters:**
| Parameter | Type | Required | Description |
| ----------- | ------ | -------- | ----------- |
| `repo` | string | Yes | Repository |
| `pr_number` | int | Yes | PR number |
#### `get_pr_diff`
Get the diff for a PR.
**Parameters:**
| Parameter | Type | Required | Description |
| ----------- | ------ | -------- | ----------- |
| `repo` | string | Yes | Repository |
| `pr_number` | int | Yes | PR number |
#### `create_pull_request`
Create a new PR.
**Parameters:**
| Parameter | Type | Required | Description |
| --------- | ------ | -------- | -------------- |
| `repo` | string | Yes | Repository |
| `title` | string | Yes | PR title |
| `body` | string | Yes | PR description |
| `head` | string | Yes | Head branch |
| `base` | string | Yes | Base branch |
This tool requires write permissions and may be disabled by default.
### Issue Tools
#### `list_issues`
List repository issues.
**Parameters:**
| Parameter | Type | Required | Description |
| --------- | ------ | -------- | ------------ |
| `repo` | string | Yes | Repository |
| `state` | string | No | open, closed |
| `labels` | string | No | Label filter |
#### `create_issue_comment`
Add comment to an issue.
**Parameters:**
| Parameter | Type | Required | Description |
| -------------- | ------ | -------- | ------------ |
| `repo` | string | Yes | Repository |
| `issue_number` | int | Yes | Issue number |
| `body` | string | Yes | Comment text |
### GitHub Actions Tools
#### `get_workflow_runs`
List workflow runs.
**Parameters:**
| Parameter | Type | Required | Description |
| ------------- | ------ | -------- | ---------------- |
| `repo` | string | Yes | Repository |
| `workflow_id` | string | No | Workflow file |
| `status` | string | No | success, failure |
#### `get_workflow_run_logs`
Get logs from a workflow run.
**Parameters:**
| Parameter | Type | Required | Description |
| --------- | ------ | -------- | ----------- |
| `repo` | string | Yes | Repository |
| `run_id` | int | Yes | Run ID |
**Example:**
```
@incidentfox get logs from the failing GitHub Actions run
```
#### `get_check_runs`
Get check runs for a commit.
**Parameters:**
| Parameter | Type | Required | Description |
| --------- | ------ | -------- | ----------- |
| `repo` | string | Yes | Repository |
| `ref` | string | Yes | Commit SHA |
### Git Tools
#### `git_diff`
Show changes between commits.
**Parameters:**
| Parameter | Type | Required | Description |
| --------- | ------ | -------- | ----------- |
| `repo` | string | Yes | Repository |
| `base` | string | Yes | Base ref |
| `head` | string | Yes | Head ref |
#### `git_blame`
Show who changed what in a file.
**Parameters:**
| Parameter | Type | Required | Description |
| --------- | ------ | -------- | ----------- |
| `repo` | string | Yes | Repository |
| `path` | string | Yes | File path |
#### `git_log`
Show commit history.
**Parameters:**
| Parameter | Type | Required | Description |
| --------- | ------ | -------- | ----------- |
| `repo` | string | Yes | Repository |
| `path` | string | No | File path |
| `since` | string | No | Start date |
## Use Cases
### CI Failure Analysis
```
@incidentfox why is the build failing on PR #123?
```
IncidentFox will:
1. `get_pull_request` - Get PR details
2. `get_check_runs` - Find failing checks
3. `get_workflow_run_logs` - Get failure logs
4. `get_pr_diff` - Analyze code changes
5. Correlate to identify root cause
### Deployment Correlation
```
@incidentfox what changed in the payments service recently?
```
IncidentFox will:
1. `list_pull_requests` - Recent merged PRs
2. `git_log` - Recent commits
3. `get_pr_diff` - Changes in each PR
### Code Investigation
```
@incidentfox find where database connections are configured
```
IncidentFox will:
1. `search_github_code` - Find relevant files
2. `read_github_file` - Read configuration
3. `git_blame` - Find who last changed it
## Required Token Scopes
| Scope | Purpose |
| ------------------ | ---------------------- |
| `repo` | Read code, PRs, issues |
| `workflow` | Access GitHub Actions |
| `write:discussion` | Post comments |
## Next Steps
Add your own tools
Set up GitHub bot
# Kubernetes Tools
Source: https://docs.incidentfox.ai/tools/kubernetes
Tools for Kubernetes troubleshooting and monitoring
## Overview
The Kubernetes tools enable IncidentFox to troubleshoot pods, deployments, and services in your clusters.
## Configuration
```json theme={null}
{
"tools": {
"kubernetes": {
"enabled": true,
"kubeconfig_path": "~/.kube/config",
"default_namespace": "production",
"default_context": "prod-cluster"
}
}
}
```
## Available Tools
### `get_pod_logs`
Fetch logs from a pod.
**Parameters:**
| Parameter | Type | Required | Description |
| ------------ | ------ | -------- | ------------------------------ |
| `pod_name` | string | Yes | Pod name or pattern |
| `namespace` | string | No | Namespace (uses default) |
| `container` | string | No | Container name |
| `tail_lines` | int | No | Number of lines (default: 100) |
| `since` | string | No | Time duration (e.g., "1h") |
**Example:**
```
@incidentfox get logs from cart-pod in production namespace, last 50 lines
```
**Response:**
```json theme={null}
{
"pod": "cart-7f9d8b6c4f-abc12",
"container": "cart",
"logs": [
"2024-01-15T10:30:00Z INFO Starting cart service",
"2024-01-15T10:30:01Z ERROR Connection refused to redis"
]
}
```
### `describe_pod`
Get pod status and configuration.
**Parameters:**
| Parameter | Type | Required | Description |
| ----------- | ------ | -------- | ----------- |
| `pod_name` | string | Yes | Pod name |
| `namespace` | string | No | Namespace |
**Example:**
```
@incidentfox describe cart-pod in production
```
**Response:**
```json theme={null}
{
"name": "cart-7f9d8b6c4f-abc12",
"namespace": "production",
"status": "Running",
"node": "ip-10-0-1-123.ec2.internal",
"ip": "10.0.1.45",
"containers": [
{
"name": "cart",
"image": "acme/cart:v2.3.0",
"state": "Running",
"restarts": 0
}
],
"conditions": [
{"type": "Ready", "status": "True"},
{"type": "ContainersReady", "status": "True"}
]
}
```
### `list_pods`
List pods in a namespace with status.
**Parameters:**
| Parameter | Type | Required | Description |
| ---------------- | ------ | -------- | ------------------------------- |
| `namespace` | string | No | Namespace |
| `label_selector` | string | No | Label filter (e.g., "app=cart") |
| `field_selector` | string | No | Field filter |
**Example:**
```
@incidentfox list pods in production namespace with app=checkout label
```
### `get_pod_events`
Get Kubernetes events for a pod or namespace.
**Parameters:**
| Parameter | Type | Required | Description |
| ----------- | ------ | -------- | --------------- |
| `name` | string | No | Resource name |
| `namespace` | string | No | Namespace |
| `type` | string | No | Normal, Warning |
**Example:**
```
@incidentfox get warning events for cart pods
```
**Response:**
```json theme={null}
{
"events": [
{
"type": "Warning",
"reason": "BackOff",
"message": "Back-off restarting failed container",
"last_timestamp": "2024-01-15T10:30:00Z",
"count": 5
}
]
}
```
### `describe_deployment`
Get deployment status and configuration.
**Parameters:**
| Parameter | Type | Required | Description |
| ----------------- | ------ | -------- | --------------- |
| `deployment_name` | string | Yes | Deployment name |
| `namespace` | string | No | Namespace |
**Example:**
```
@incidentfox describe checkout deployment
```
### `get_deployment_history`
View rollout history.
**Parameters:**
| Parameter | Type | Required | Description |
| ----------------- | ------ | -------- | --------------- |
| `deployment_name` | string | Yes | Deployment name |
| `namespace` | string | No | Namespace |
**Example:**
```
@incidentfox show rollout history for payments deployment
```
### `describe_service`
Get service details and endpoints.
**Parameters:**
| Parameter | Type | Required | Description |
| -------------- | ------ | -------- | ------------ |
| `service_name` | string | Yes | Service name |
| `namespace` | string | No | Namespace |
### `get_pod_resource_usage`
Get CPU/memory usage for pods.
**Parameters:**
| Parameter | Type | Required | Description |
| ----------- | ------ | -------- | ------------ |
| `namespace` | string | No | Namespace |
| `pod_name` | string | No | Specific pod |
Requires metrics-server installed in the cluster.
**Example:**
```
@incidentfox check resource usage for checkout pods
```
**Response:**
```json theme={null}
{
"pods": [
{
"name": "checkout-abc12",
"cpu": "250m",
"memory": "512Mi",
"cpu_request": "200m",
"memory_request": "256Mi",
"cpu_limit": "500m",
"memory_limit": "1Gi"
}
]
}
```
### `docker_exec`
Execute commands in containers.
**Parameters:**
| Parameter | Type | Required | Description |
| ----------- | ------ | -------- | ------------------ |
| `pod_name` | string | Yes | Pod name |
| `namespace` | string | No | Namespace |
| `container` | string | No | Container name |
| `command` | string | Yes | Command to execute |
This tool may be disabled by default for security. Enable only if needed.
## Use Cases
### Investigating Pod Crashes
```
@incidentfox why is the cart pod crashing?
```
IncidentFox will:
1. `list_pods` - Check pod status
2. `get_pod_events` - Find crash reasons
3. `get_pod_logs` - Read logs before crash
4. `describe_pod` - Check configuration
### Checking Resource Issues
```
@incidentfox check if checkout pods have resource issues
```
IncidentFox will:
1. `get_pod_resource_usage` - Current usage
2. `get_pod_events` - OOMKilled events
3. `describe_deployment` - Configured limits
### Verifying Deployments
```
@incidentfox verify the latest deployment of payments service
```
IncidentFox will:
1. `describe_deployment` - Check status
2. `get_deployment_history` - Recent rollouts
3. `list_pods` - Pod status
## Required RBAC
```yaml theme={null}
rules:
- apiGroups: [""]
resources: ["pods", "pods/log", "services", "events"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["deployments", "replicasets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["metrics.k8s.io"]
resources: ["pods"]
verbs: ["get", "list"]
```
## Next Steps
AWS infrastructure tools
Full K8s setup guide
# Log Analysis Tools
Source: https://docs.incidentfox.ai/tools/log-analysis
Advanced log analysis capabilities for pattern detection and anomaly identification
## Overview
IncidentFox provides 7 specialized log analysis tools that work across any log backend (CloudWatch, Elasticsearch, Coralogix, Splunk, etc.). These tools help identify patterns, anomalies, and correlations in log data.
## Tools Available
| Tool | Description |
| ------------------------ | --------------------------------------------------- |
| `log_get_statistics` | Get log volume, error rates, and distribution stats |
| `log_sample` | Sample logs for pattern discovery |
| `log_search_pattern` | Search for specific patterns using regex |
| `log_around_timestamp` | Get context around a specific event |
| `log_correlate_events` | Correlate events across services |
| `log_extract_signatures` | Identify recurring error patterns |
| `log_detect_anomalies` | Find unusual log patterns |
## log\_get\_statistics
Get statistical overview of log data:
```
@incidentfox show me log statistics for the payments service over the last hour
```
**Returns:**
* Total log volume
* Error rate percentage
* Log level distribution
* Top error messages
* Throughput over time
## log\_sample
Sample logs to understand patterns without overwhelming data:
```
@incidentfox sample 100 error logs from the checkout service
```
**Use cases:**
* Initial investigation to understand error types
* Pattern discovery before targeted searches
* Representative data for analysis
## log\_search\_pattern
Search for specific patterns using regex:
```
@incidentfox search for "timeout after [0-9]+ ms" in the api service logs
```
**Supports:**
* Full regex syntax
* Case-insensitive matching
* Multi-line patterns
## log\_around\_timestamp
Get context around a specific event:
```
@incidentfox show me logs 5 minutes before and after the error at 14:32:15 UTC
```
**Returns:**
* Logs from the target service
* Related logs from dependent services
* System events in the timeframe
## log\_correlate\_events
Correlate events across services using trace IDs or request IDs:
```
@incidentfox correlate logs for trace ID abc-123-def
```
**Returns:**
* Timeline of events across services
* Latency breakdown by service
* Error propagation path
## log\_extract\_signatures
Identify recurring error patterns automatically:
```
@incidentfox extract error signatures from the last 24 hours
```
**Process:**
1. Clusters similar log messages
2. Extracts common patterns (parameterized)
3. Ranks by frequency and impact
**Example output:**
```json theme={null}
{
"signatures": [
{
"pattern": "Connection refused to {host}:{port}",
"count": 1234,
"first_seen": "2024-01-15T10:00:00Z",
"last_seen": "2024-01-15T14:30:00Z"
}
]
}
```
## log\_detect\_anomalies
Find unusual patterns in log data:
```
@incidentfox detect anomalies in the api service logs
```
**Detects:**
* Unusual log volume spikes/drops
* New error types not seen before
* Abnormal patterns in log messages
## Configuration
### Backend Selection
Configure which log backend to use:
```json theme={null}
{
"tools": {
"log_analysis": {
"default_backend": "elasticsearch",
"backends": {
"elasticsearch": {
"hosts": ["https://es.your-domain.com:9200"]
},
"cloudwatch": {
"log_group_prefix": "/aws/lambda/"
}
}
}
}
}
```
### Sampling Settings
```json theme={null}
{
"tools": {
"log_analysis": {
"default_sample_size": 100,
"max_sample_size": 1000
}
}
}
```
## Use Cases
### Error Investigation
1. Start with `log_get_statistics` to understand volume
2. Use `log_sample` to see representative errors
3. Apply `log_extract_signatures` to identify patterns
4. Drill down with `log_search_pattern`
### Incident Timeline
1. Identify incident start with `log_detect_anomalies`
2. Get context with `log_around_timestamp`
3. Trace across services with `log_correlate_events`
### Proactive Monitoring
1. Run `log_detect_anomalies` to find new issues
2. Extract signatures to track recurring problems
3. Correlate with deployment events
## Best Practices
### Time Ranges
Start with narrow time ranges and expand if needed:
* Initial investigation: 1 hour
* Pattern analysis: 24 hours
* Trend analysis: 7 days
### Filtering
Use service/component filters to reduce noise:
```
@incidentfox search for errors in the checkout service, excluding health checks
```
### Correlation IDs
Ensure your services log correlation IDs for effective tracing:
* Trace ID (OpenTelemetry)
* Request ID
* Session ID
## Next Steps
Metric anomaly detection
Configure Elasticsearch
# Observability Tools
Source: https://docs.incidentfox.ai/tools/observability
Tools for metrics, logs, and traces from observability platforms
## Overview
Observability tools connect IncidentFox to your monitoring stack including Grafana, Datadog, Coralogix, and New Relic.
## Grafana Tools
### `grafana_query_prometheus`
Query Prometheus metrics via Grafana.
**Parameters:**
| Parameter | Type | Required | Description |
| --------- | ------ | -------- | ------------ |
| `query` | string | Yes | PromQL query |
| `start` | string | No | Start time |
| `end` | string | No | End time |
| `step` | string | No | Query step |
**Example:**
```
@incidentfox query prometheus for rate(http_requests_total[5m]) by service
```
### `grafana_get_dashboard`
Get dashboard panels and data.
**Parameters:**
| Parameter | Type | Required | Description |
| --------------- | ------ | -------- | ------------- |
| `dashboard_uid` | string | Yes | Dashboard UID |
### `grafana_get_alerts`
Check alert status.
**Parameters:**
| Parameter | Type | Required | Description |
| --------- | ------ | -------- | --------------------- |
| `state` | string | No | alerting, ok, pending |
## Datadog Tools
### `query_datadog_metrics`
Query Datadog metrics.
**Parameters:**
| Parameter | Type | Required | Description |
| --------- | ------ | -------- | -------------------- |
| `query` | string | Yes | Datadog metric query |
| `from` | int | No | Start time (Unix) |
| `to` | int | No | End time (Unix) |
**Example:**
```
@incidentfox query datadog for avg:system.cpu.user{service:checkout}
```
### `search_datadog_logs`
Search Datadog logs.
**Parameters:**
| Parameter | Type | Required | Description |
| --------- | ------ | -------- | ---------------- |
| `query` | string | Yes | Log search query |
| `from` | string | No | Start time |
| `to` | string | No | End time |
| `limit` | int | No | Max results |
### `get_service_apm_metrics`
Get APM metrics for a service.
**Parameters:**
| Parameter | Type | Required | Description |
| --------- | ------ | -------- | ------------ |
| `service` | string | Yes | Service name |
| `env` | string | No | Environment |
## Coralogix Tools
### `search_coralogix_logs`
Search logs in Coralogix.
**Parameters:**
| Parameter | Type | Required | Description |
| ------------- | ------ | -------- | ------------------ |
| `query` | string | Yes | Lucene query |
| `application` | string | No | Application filter |
| `subsystem` | string | No | Subsystem filter |
| `start_time` | string | No | Start time |
| `end_time` | string | No | End time |
**Example:**
```
@incidentfox search coralogix for "error" AND "timeout" in payments application
```
### `get_coralogix_metrics`
Query Coralogix metrics.
**Parameters:**
| Parameter | Type | Required | Description |
| ------------- | ------ | -------- | ------------- |
| `metric_name` | string | Yes | Metric name |
| `aggregation` | string | No | sum, avg, max |
| `filters` | dict | No | Label filters |
### `get_coralogix_alerts`
Get recent alerts from Coralogix.
**Parameters:**
| Parameter | Type | Required | Description |
| ---------- | ------ | -------- | ---------------- |
| `severity` | string | No | Severity filter |
| `status` | string | No | active, resolved |
## New Relic Tools
### `query_newrelic_nrql`
Run NRQL queries.
**Parameters:**
| Parameter | Type | Required | Description |
| ------------ | ------ | -------- | ----------- |
| `query` | string | Yes | NRQL query |
| `account_id` | string | No | Account ID |
**Example:**
```sql theme={null}
SELECT count(*) FROM Transaction
WHERE appName = 'checkout'
FACET error.class
SINCE 1 hour ago
```
### `get_apm_summary`
Get APM summary for an application.
**Parameters:**
| Parameter | Type | Required | Description |
| ---------- | ------ | -------- | ---------------- |
| `app_name` | string | Yes | Application name |
## Anomaly Detection Tools
These tools use Prophet and statistical methods:
### `detect_anomalies`
Detect anomalies in metric data.
**Parameters:**
| Parameter | Type | Required | Description |
| ------------- | ----- | -------- | --------------------- |
| `metric_data` | list | Yes | Time series data |
| `sensitivity` | float | No | Detection sensitivity |
### `correlate_metrics`
Find correlations between metrics.
**Parameters:**
| Parameter | Type | Required | Description |
| ------------ | ------ | -------- | -------------- |
| `metrics` | list | Yes | Metric queries |
| `time_range` | string | No | Time range |
### `find_change_points`
Identify change points in metrics.
**Parameters:**
| Parameter | Type | Required | Description |
| ------------- | ---- | -------- | ---------------- |
| `metric_data` | list | Yes | Time series data |
## Use Cases
### Cross-Platform Investigation
```
@incidentfox investigate high latency using Grafana and Coralogix data
```
IncidentFox will:
1. `grafana_query_prometheus` - Get latency metrics
2. `search_coralogix_logs` - Find error patterns
3. `correlate_metrics` - Link to other services
4. `detect_anomalies` - Identify unusual patterns
### Alert Investigation
```
@incidentfox get context for the Datadog alert on checkout service
```
## Configuration
```json theme={null}
{
"tools": {
"grafana": {
"enabled": true,
"url": "https://grafana.company.com",
"api_key": "vault://secrets/grafana-key"
},
"datadog": {
"enabled": true,
"api_key": "vault://secrets/dd-api-key",
"app_key": "vault://secrets/dd-app-key"
},
"coralogix": {
"enabled": true,
"api_key": "vault://secrets/coralogix-key",
"domain": "coralogix.com"
}
}
}
```
## Next Steps
Code and CI/CD tools
Add your own tools
# Tools Catalog
Source: https://docs.incidentfox.ai/tools/overview
Complete reference of 300+ tools available in IncidentFox
## Overview
IncidentFox provides 300+ built-in tools across 20+ categories. These tools enable agents to interact with your infrastructure, observability stack, databases, and collaboration platforms.
## Tool Categories
| Category | Tools | Description |
| --------------------------------------------- | --------- | ------------------------------------------------------- |
| [Kubernetes](/tools/kubernetes) | 9 | Pod logs, deployments, events, resource usage |
| [AWS](/tools/aws) | 8+ | EC2, Lambda, RDS, ECS, CloudWatch |
| [Docker](/tools/docker) | 15 | Container logs, stats, exec, events, inspect |
| [Observability](/tools/observability) | 15+ | Grafana, Datadog, Prometheus, Coralogix, New Relic |
| [Log Analysis](/tools/log-analysis) | 7 | Statistics, sampling, pattern search, anomaly detection |
| [Anomaly Detection](/tools/anomaly-detection) | 8 | Z-score, Prophet, correlation, change points |
| [GitHub](/tools/github) | 16 | Code search, PRs, issues, Actions, commits |
| [Git](/tools/git) | 12 | Diff, log, blame, branches, tags |
| [Database](/tools/database) | 70+ | MySQL, PostgreSQL, Snowflake, BigQuery |
| [PagerDuty](/tools/pagerduty) | 12 | Incidents, escalations, MTTR |
| [Sentry](/tools/sentry) | 4 | Issues, project stats, releases |
| [Slack](/tools/slack) | 5 | Search, channel history, post messages |
| [Custom MCP](/tools/custom-mcp) | Unlimited | Add your own tools via MCP (100+ compatible servers) |
## Tool Distribution by Runtime
IncidentFox uses dual agent runtimes, each with access to different tool sets:
### OpenAI SDK Agent (Production Automation)
| Agent | Tools | Purpose |
| ------------------- | ------------- | ---------------------------------------------------- |
| Planner | Orchestration | Coordinates specialists, creates investigation plans |
| K8s Agent | 9 | Kubernetes troubleshooting |
| AWS Agent | 8+ | AWS resource debugging |
| Metrics Agent | 22+ | Anomaly detection, correlation, forecasting |
| Coding Agent | 15+ | Code analysis, CI/CD |
| Investigation Agent | 300+ | All tools (dynamic loading) |
### Claude SDK SRE Agent (Interactive Debugging)
| Feature | Description |
| ----------- | ----------------------------------------------- |
| K8s Sandbox | Isolated Kubernetes environment with gVisor |
| All Tools | Full access to 300+ tools |
| Interactive | Supports interrupt/resume during investigations |
| Streaming | Real-time response streaming |
## How Tools Work
```mermaid theme={null}
graph TD
A[Agent] -->|Tool Request| B{Tool Loader}
B -->|Check| C{Is tool installed?}
C -->|Yes| D{Auth configured?}
D -->|Yes| E{Tool enabled?}
E -->|Yes| F[Execute]
F --> G[External API
AWS, K8s, etc.]
```
## Tool Loading
Tools are loaded dynamically based on:
1. **Integration Installed** - Is the package available?
2. **Credentials Configured** - Are API keys set?
3. **Team Settings** - Is the tool enabled?
Example log output:
```
slack_tools_loaded: count=4
github_tools_loaded: count=16
kubernetes_tools_loaded: count=9
aws_tools_loaded: count=8
```
## Configuring Tools
### Enable/Disable
```json theme={null}
{
"tools": {
"kubernetes": {
"enabled": true
},
"docker_exec": {
"enabled": false
}
}
}
```
### Per-Agent Configuration
```json theme={null}
{
"agents": {
"investigation_agent": {
"disable_default_tools": ["shell", "docker_exec"],
"enable_extra_tools": ["custom_runbook_search"]
}
}
}
```
## Tool Metrics
All tools track:
* `tool_calls_total{tool_name, status}` - Call count
* `tool_duration_seconds{tool_name}` - Execution time
View in Prometheus or the Web UI under **Agent Runs**.
## Common Tools
### Most Used for Investigations
| Tool | Category | Description |
| --------------------- | ----------------- | ------------------------------------ |
| `get_pod_logs` | Kubernetes | Fetch container logs |
| `get_cloudwatch_logs` | AWS | Query CloudWatch logs |
| `search_logs` | Log Analysis | Universal log search across backends |
| `query_prometheus` | Observability | Query Grafana/Prometheus |
| `detect_anomalies` | Anomaly Detection | Find unusual patterns in metrics |
| `search_github_code` | GitHub | Search across repos |
### Most Used for CI/CD
| Tool | Category | Description |
| --------------------------- | -------- | ----------------------------- |
| `get_github_actions_logs` | GitHub | CI build logs |
| `describe_codepipeline` | AWS | Pipeline status |
| `read_github_file` | GitHub | Read code files |
| `git_diff` | Git | Show changes |
| `correlate_with_deployment` | Git | Link issues to recent deploys |
### Most Used for Log Analysis
| Tool | Category | Description |
| ------------------------ | ------------ | ----------------------------------- |
| `log_get_statistics` | Log Analysis | Get log volume and error rate stats |
| `log_sample` | Log Analysis | Sample logs for pattern discovery |
| `log_search_pattern` | Log Analysis | Regex pattern search |
| `log_around_timestamp` | Log Analysis | Get context around an event |
| `log_extract_signatures` | Log Analysis | Identify recurring error patterns |
### Most Used for Anomaly Detection
| Tool | Category | Description |
| -------------------------- | ----------------- | ---------------------------------- |
| `detect_anomalies` | Anomaly Detection | Z-score statistical detection |
| `prophet_detect_anomalies` | Anomaly Detection | Seasonal anomaly detection |
| `find_change_point` | Anomaly Detection | Identify when issues started |
| `correlate_metrics` | Anomaly Detection | Find relationships between metrics |
| `forecast_metric` | Anomaly Detection | Capacity planning forecasts |
## Next Steps
K8s troubleshooting tools
AWS infrastructure tools
Metrics and logging tools
Add your own tools