Operations runbooks
Respond to BlendDuck API, job, provider, and webhook alerts using correlated evidence.
- Documentation owner:
- BlendDuck Documentation
- Last reviewed:
The owner/admin Operations page evaluates tenant-scoped signals every time it loads and refreshes every 30 seconds. Start with the alert's trace and correlation IDs. Never paste credentials, raw callback bodies, customer content, email addresses, or phone numbers into an incident record.
API errors
- Confirm whether failures share one operation and deployment version.
- Follow the trace into the application audit using the correlation ID.
- Separate
4xxcaller errors from5xxapplication/dependency errors. - If a release caused the regression, stop rollout and use the documented change-control rollback. Do not mutate production data to make a probe pass.
- Resolve only after a complete healthy evaluation window; a quiet window is insufficient evidence.
API latency
- Compare p95 by operation and identify whether provider or database spans dominate.
- Check database health and current job backlog before increasing limits.
- Confirm the issue with persisted production-shaped inputs; fixture-only performance is not evidence of recovery.
- Roll back the offending release or isolate the dependency, then verify a healthy 15-minute window.
Job failures
- Inspect the job name, attempt, backend, and correlation trail.
- Load the referenced persisted resource; never trust a workspace ID supplied by an external payload.
- Classify the error as retryable, terminal, permission, or invalid content.
- Repair the cause before replay. Keep the original idempotency key and do not publish or trigger a paid provider action without explicit approval.
- Confirm the resource and application audit reached the intended tenant.
Provider errors
- Group by provider, status, and operation; do not inspect or log tokens.
- For
401/403, revalidate current account ownership, scopes, and token state. - For
429, respect the provider's retry window instead of bypassing limits. - For
5xxor network failures, preserve idempotency and ambiguity recovery before retrying a write. - Confirm recovery with a non-destructive provider probe or an explicitly authorized sandbox action.
Webhook failures
- Confirm the exact public callback URL and raw-body signature algorithm.
- Treat payload tenant hints as untrusted; route only through signed state or a globally unique provider identity.
- Check replay identity and monotonic state handling before reprocessing.
- Never disable signature validation to clear the alert.
- Verify a signed callback reaches one tenant and records an application audit before resolving.
Escalation record
Record the alert rule, first/last trigger, deployment version, trace and correlation IDs, impact, owner, mitigation, verification, and follow-up. Use sanitized references only. Security or privacy incidents follow the incident response and data-breach decision process; provider outages follow the relevant provider status and support channel.