Self-Healing

Self-healing automatically mitigates errors by toggling feature flags, redirecting traffic, or triggering webhooks when error thresholds are breached. The SDK polls for flag changes and applies them without a page reload.

Feature flag integration

Define healing rules that automatically disable features when they cause too many errors. Each rule specifies an error group trigger, a feature flag action, and optional auto-reenable conditions.

{
  "name": "Disable broken chat widget",
  "trigger": {
    "errorGroup": "ChatWidgetCrash",
    "threshold": 50,
    "window": "5m"
  },
  "action": {
    "type": "disable_feature",
    "featureFlag": "chat_widget_enabled",
    "scope": "all_users"
  },
  "autoReenable": {
    "enabled": true,
    "afterMinutes": 30,
    "requiresZeroErrors": true
  }
}

Healing action types

Gurulu supports multiple action types that can be triggered when a healing rule fires:

• Disable feature -- sets a feature flag to false, preventing the problematic code from running.
• Rollback -- triggers a webhook to your deployment system to roll back to the previous release.
• Redirect -- redirects users away from the broken page to a fallback URL.
• Fallback content -- replaces the broken component with a static fallback via the SDK.
• Webhook -- sends a notification to an external system for custom handling.

SDK polling mechanism

The Gurulu SDK polls the flag service at a configurable interval. When a healing action changes a flag value, the SDK applies the change immediately without requiring a page reload.

import { init } from '@gurulu/web';

init({
  siteId: 'YOUR_SITE_ID',
  token: 'YOUR_TOKEN',
  selfHealing: {
    enabled: true,
    pollIntervalMs: 30000,    // check for flag changes every 30s
    onFlagChange: (flag, value) => {
      console.log(`Feature ${flag} changed to ${value}`);
    },
  },
});

// Check feature flag status in your app
import { isFeatureEnabled } from '@gurulu/web';

if (isFeatureEnabled('chat_widget_enabled')) {
  renderChatWidget();
}

Auto-reenable conditions

Disabled features can be automatically re-enabled when conditions are met:

• Timer-based -- re-enable after a fixed number of minutes.
• Zero-error -- re-enable only when the error group has zero occurrences for the specified duration.
• Manual -- require manual intervention via dashboard or CLI.
• Gradual rollout -- re-enable to a percentage of traffic in stages, rolling back if errors recur.

{
  "autoReenable": {
    "strategy": "gradual",
    "stages": [
      { "percentTraffic": 10, "durationMinutes": 15 },
      { "percentTraffic": 50, "durationMinutes": 30 },
      { "percentTraffic": 100, "durationMinutes": 0 }
    ],
    "rollbackOnError": true
  }
}

Webhook triggers

Every healing action fires a webhook notification so your team stays informed. The payload includes the rule name, error group, action taken, and auto-reenable schedule:

{
  "event": "self_healing.action_triggered",
  "timestamp": "2026-04-19T10:30:00Z",
  "data": {
    "ruleName": "Disable broken chat widget",
    "errorGroup": "ChatWidgetCrash",
    "action": "disable_feature",
    "featureFlag": "chat_widget_enabled",
    "affectedSessions": 127,
    "autoReenableAt": "2026-04-19T11:00:00Z"
  }
}

CLI commands

# List healing rules
gurulu healing list --site-id YOUR_SITE_ID

# View healing history
gurulu healing history --site-id YOUR_SITE_ID --window 7d

# Manually re-enable a disabled feature
gurulu healing reenable --site-id YOUR_SITE_ID --flag chat_widget_enabled

# Dry-run a healing rule
gurulu healing test --site-id YOUR_SITE_ID --rule "Disable broken chat widget"

Related features: Alerting and Stability.