Algolia Search Incident Runbook
Overview
This skill runs a product-owned incident process without assuming the provider is or is not at fault. Severity and response targets come from the organization's runbook, while diagnosis uses application, provider, and data-pipeline evidence.
Prerequisites
- A named repository, environment, and Algolia application or index in scope
- The local lockfile and installed client types as implementation authority
- A safe read-only query or explicitly disposable test target
- Current first-party documentation for any provider behavior that affects the change
Tool Discipline
Use Read, Glob, and Grep to inspect local code, configuration names, tests, and dependency versions. Use WebFetch only for current official Algolia documentation. Use Write or Edit only after identifying the target files, constraints, and verification plan.
Current Contract
- Separate availability, authorization, freshness, latency, relevance, and event-collection symptoms.
- Check provider status as one signal, not as the root-cause conclusion.
- Preserve request IDs, task IDs, deployment SHAs, settings changes, and source snapshots.
- Prefer traffic rollback, prior index targets, or feature degradation paths that are already tested.
Authentication
Use read-only or narrowly scoped incident credentials. Never paste keys into tickets, chat, commands, screenshots, or diagnostic bundles.
Instructions
- Declare incident owner, affected journey, start time, severity source, and current user impact.
- Freeze unrelated changes and capture recent releases, indexing runs, key changes, and provider status.
- Run a known read-only query and compare application, direct client, and source-of-truth results.
- Classify the failure surface and choose the smallest reversible containment.
- Verify recovery with synthetic and representative user queries, not only HTTP success.
- Record timeline, evidence, decisions, cleanup, follow-up owners, and rollback readiness.
Approval Boundaries
Do not invent severity targets, rotate credentials, rebuild production, change relevance settings, or delete an index without the incident commander's approval.
Output
Return the incident classification, timeline, evidence links, containment action, recovery checks, customer impact, unresolved risks, and follow-up tasks.
Error Handling
| Condition | Response |
|---|---|
| Provider status unclear | Continue application and data-path diagnosis while monitoring official status. |
| Credential suspected exposed | Escalate rotation through the approved secret process. |
| Freshness mismatch | Trace source snapshot and task completion before reindexing. |
| Recovery changes relevance | Rollback or obtain product-owner acceptance. |
Examples
Use this compact input and expected handoff to calibrate scope and evidence quality.
Input:
incident=SEV-from-company-runbook; symptom=stale-products; provider-status=operational
Expected handoff:
cause=indexing-task-failed; containment=previous-index; verification=12/12-queries-pass