Notifications & Git

Risoluto integrates with Slack for notifications and GitHub for automated git workflows.

Notification Channels

Slack Webhook
Generic Webhook (Inbound from Linear)

Configure Slack to receive alerts when agents complete, fail, or stall:

notifications:
  channels:
    - type: slack
      name: slack
      webhookUrl: $SECRET:SLACK_WEBHOOK_URL
      verbosity: critical  # off | critical | verbose

# Store the webhook URL as a secret
curl -s -X POST http://127.0.0.1:4000/api/v1/secrets/SLACK_WEBHOOK_URL \
  -H 'Content-Type: application/json' \
  -d '{"value":"https://hooks.slack.com/services/T.../B.../xxx"}'

# Enable Slack notifications via channels[]
curl -s -X PUT http://127.0.0.1:4000/api/v1/config/overlay \
  -H 'Content-Type: application/json' \
  -d '{"notifications":{"channels":[{"type":"slack","name":"slack","webhookUrl":"$SECRET:SLACK_WEBHOOK_URL","verbosity":"critical"}]}}'

The legacy notifications.slack.webhookUrl shape is still accepted and is automatically promoted to channels[] at parse time. New configurations should use channels[] directly.

Slack messages are formatted with Block Kit — each notification includes a header, issue context, event details, and a link back to the Linear issue.

Risoluto can receive webhooks directly from Linear for near-instant issue dispatch (instead of polling every 15s):

webhook:
  webhookUrl: "https://your-server.example.com/webhooks/linear"
  webhookSecret: $SECRET:WEBHOOK_SECRET

When a verified webhook arrives, Risoluto processes the issue update immediately and stretches the polling interval to reduce API load.

Key	Default	Description
`webhook.webhookUrl`	—	HTTPS-only webhook endpoint
`webhook.webhookSecret`	—	HMAC signing secret for verification
`webhook.pollingBaseMs`	`15000`	Normal polling interval
`webhook.pollingStretchMs`	`120000`	Stretched interval when webhook is healthy
`webhook.healthCheckIntervalMs`	`300000`	Health check interval (5 min)

Notification Events

Every notification carries a type, severity, and issue context:

Event Type	Severity	Trigger
`issue_claimed`	info	Issue picked up from the tracker queue
`worker_launched`	info	Agent worker container started
`worker_completed`	info	Agent finished work successfully
`worker_retry`	critical	Agent failed and is being retried
`worker_failed`	critical	Agent failed permanently (no retries left)

Verbosity Levels

Verbosity	Events Delivered
`off`	No notifications
`critical`	Only `worker_retry` and `worker_failed` (failures and errors)
`verbose`	All events including completions and claims

Notifications are best-effort. Delivery failures are logged but do not crash the orchestrator.

Deduplication Window

The notification manager deduplicates identical events within a 30-second window. An event is considered duplicate if it matches the same combination of:

Event type
Issue identifier
Attempt number
Severity
Message text

Events with an explicit dedupeKey field use that key instead. This prevents notification floods during rapid retry cycles.

Notification Payload Shape

Every notification event carries this structure:

interface NotificationEvent {
  type: NotificationEventType;       // "issue_claimed" | "worker_launched" | ...
  severity: "info" | "critical";
  timestamp: string;                 // ISO 8601
  message: string;                   // Human-readable summary
  issue: {
    id: string | null;
    identifier: string;              // e.g. "FE-123"
    title: string;
    state: string | null;
    url: string | null;              // Link to Linear issue
  };
  attempt: number | null;
  metadata?: Record<string, unknown>;
  dedupeKey?: string;
}

Repository Routing

Route issues to different repositories based on identifier prefix or Linear label. For a full walkthrough with examples, see the Multi-Repository Setup recipe.

repos:
  - prefix: "FE-"
    url: "https://github.com/org/frontend.git"
    default_branch: "main"
  - label: "backend"
    url: "https://github.com/org/backend.git"
    default_branch: "main"

Routing precedence:

Label routes are checked first (per-issue overrides)
Identifier-prefix routes are the fallback (team-to-repo mapping)

Managing Routes via API

curl -s http://127.0.0.1:4000/api/v1/setup/repo-routes

curl -s -X POST http://127.0.0.1:4000/api/v1/setup/repo-route \
  -H 'Content-Type: application/json' \
  -d '{"prefix":"API-","url":"https://github.com/org/api.git","default_branch":"main"}'

curl -s -X DELETE http://127.0.0.1:4000/api/v1/setup/repo-route/0

Git Automation

When a routed issue reports RISOLUTO_STATUS: DONE, Risoluto can automatically:

Commit

Stage and commit all changes in the workspace branch.

Push

Push the branch to the remote repository.

Open PR

Create a GitHub pull request with the issue context, agent summary, and a link back to the Linear issue.

Agents can also interact with GitHub during execution through the github_api dynamic tool — reading PR review comments, posting progress updates, and referencing related issues.

Store credentials via the setup wizard rather than environment variables. The encrypted secrets store (secrets.enc) is more secure than plaintext env vars in .env files.

Get Started

Core Concepts

Guides

Recipes

Operating

Notifications & Git

Notification Channels

Notification Events

Verbosity Levels

Repository Routing

Managing Routes via API

Git Automation

What’s Next

Security

Monitoring Stack

​Notification Channels

​Notification Events

​Verbosity Levels

​Repository Routing

​Managing Routes via API

​Git Automation

​What’s Next

Security

Monitoring Stack

Notification Channels

Notification Events

Verbosity Levels

Repository Routing

Managing Routes via API

Git Automation

What’s Next