Exa Production Checklist
Prerequisites
- A named service/policy/data owner, approved model/provider route, production rollback plan, and passing staging evidence.
Instructions
- Complete evidence gates for identity/secrets, data handling, policy controls, source/citation requirements, observability, rate limits, and rollback.
- Validate an approved non-sensitive canary and verify its expected routing/guardrail behavior.
- Block release when any security, policy, data, ownership, or recovery gate is unverified.
Output
- A production-readiness receipt with evidence, owners, exceptions, canary result, and rollback path.
Examples
Release an approved staging configuration to a small canary using sanitized queries, verify policy/source/citation and alert behavior, then observe the defined window. Restore the previous configuration if any guardrail or SLO fails; do not widen automation to conceal a failure.
Overview
Complete checklist for deploying Exa search integrations to production. Covers API key management, error handling verification, performance baselines, monitoring, and rollback procedures.
Pre-Deployment Checklist
Security
Code Quality
Performance
Monitoring
Deploy Procedure
Step 1: Pre-Flight Verification
set -euo pipefail
echo "=== Exa Pre-Flight ==="
# 1. Verify production API key works
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" \
-X POST https://api.exa.ai/search \
-H "x-api-key: $EXA_API_KEY_PROD" \
-H "Content-Type: application/json" \
-d '{"query":"pre-flight check","numResults":1}')
echo "API Status: $HTTP_CODE"
[ "$HTTP_CODE" = "200" ] || { echo "FAIL: API key invalid"; exit 1; }
# 2. Verify tests pass
npm test || { echo "FAIL: Tests failing"; exit 1; }
echo "Pre-flight PASSED"
Step 2: Health Check Endpoint
import Exa from "exa-js";
const exa = new Exa(process.env.EXA_API_KEY);
app.get("/health/exa", async (_req, res) => {
const start = performance.now();
try {
const result = await exa.search("health check", { numResults: 1 });
const latencyMs = Math.round(performance.now() - start);
res.json({
status: "healthy",
latencyMs,
resultCount: result.results.length,
timestamp: new Date().toISOString(),
});
} catch (err: any) {
res.status(503).json({
status: "unhealthy",
error: err.message,
errorCode: err.status,
latencyMs: Math.round(performance.now() - start),
});
}
});
Step 3: Gradual Rollout
set -euo pipefail
# Deploy canary (10% traffic)
kubectl apply -f k8s/production.yaml
kubectl rollout pause deployment/exa-service
echo "Canary deployed. Monitor for 10 minutes..."
echo "Check: /health/exa endpoint, error rates, latency"
# After monitoring, resume to full rollout
# kubectl rollout resume deployment/exa-service
Post-Deployment Verification
set -euo pipefail
# Verify production endpoint
curl -sf https://your-app.com/health/exa | python3 -m json.tool
# Check error rates (if Prometheus available)
curl -s "localhost:9090/api/v1/query?query=rate(exa_search_error[5m])" 2>/dev/null
Rollback Procedure
set -euo pipefail
# Immediate rollback
kubectl rollout undo deployment/exa-service
kubectl rollout status deployment/exa-service
echo "Rollback complete. Verify /health/exa endpoint."
Alert Thresholds
| Alert |
Condition |
Severity |
| API Down |
5xx errors > 10/min |
P1 |
| Auth Failure |
401/403 errors > 0 |
P1 |
| Rate Limited |
429 errors > 5/min |
P2 |
| High Latency |
P95 > 5000ms |
P2 |
| Budget Warning |
Daily searches > 80% of limit |
P3 |
Error Handling
| Issue |
Cause |
Solution |
| Health check fails |
API key not set in prod |
Verify secret injection |
| Latency spike after deploy |
Missing cache warm-up |
Pre-populate cache |
| Rate limit on launch |
Traffic spike |
Enable request queue |
| Rollback needed |
Error rate spike |
kubectl rollout undo |
Resources
Next Steps
For version upgrades, see exa-upgrade-migration. For incident response, see exa-incident-runbook.
1---2name: exa-prod-checklist3description: Execute Exa production deployment checklist with pre-flight, deploy, and rollback. Use when deploying Exa integrations to production, preparing for launch, or verifying production readiness. Trigger with phrases like "exa production", "deploy exa to prod", "exa go-live", "exa launch checklist", "exa production ready".4license: MIT5---6# Exa Production Checklist
7
8## Prerequisites
9
10- A named service/policy/data owner, approved model/provider route, production rollback plan, and passing staging evidence.
11
12## Instructions
13
141. Complete evidence gates for identity/secrets, data handling, policy controls, source/citation requirements, observability, rate limits, and rollback.
152. Validate an approved non-sensitive canary and verify its expected routing/guardrail behavior.
163. Block release when any security, policy, data, ownership, or recovery gate is unverified.
17
18## Output
19
20- A production-readiness receipt with evidence, owners, exceptions, canary result, and rollback path.
21
22## Examples
23
24Release an approved staging configuration to a small canary using sanitized queries, verify policy/source/citation and alert behavior, then observe the defined window. Restore the previous configuration if any guardrail or SLO fails; do not widen automation to conceal a failure.
25
26## Overview
27
28Complete checklist for deploying Exa search integrations to production. Covers API key management, error handling verification, performance baselines, monitoring, and rollback procedures.
29
30## Pre-Deployment Checklist
31
32### Security
33
34- [ ] Production API key stored in secret manager (not env file)
35- [ ] Different API keys for dev/staging/production
36- [ ] `.env` files in `.gitignore`
37- [ ] Git history scanned for accidentally committed keys
38- [ ] API key has minimal scopes needed
39
40### Code Quality
41
42- [ ] All tests passing (unit + integration)
43- [ ] No hardcoded API keys or URLs
44- [ ] Error handling covers all Exa HTTP codes (400, 401, 402, 403, 429, 5xx)
45- [ ] `requestId` captured from error responses
46- [ ] Rate limiting/exponential backoff implemented
47- [ ] Content moderation enabled (`moderation: true`) for user-facing search
48
49### Performance
50
51- [ ] Search type appropriate for latency SLO (`fast`/`auto`/`neural`)
52- [ ] `numResults` minimized per use case (3-5 for most)
53- [ ] `maxCharacters` set on text and highlights
54- [ ] Result caching enabled (LRU or Redis)
55- [ ] Request queue with concurrency limit (respect 10 QPS default)
56
57### Monitoring
58
59- [ ] Search latency histogram instrumented
60- [ ] Error rate counter by status code
61- [ ] Cache hit/miss rate tracked
62- [ ] Daily search volume tracked (for budget)
63- [ ] Alerts configured for latency > 3s, error rate > 5%
64
65## Deploy Procedure
66
67### Step 1: Pre-Flight Verification
68
69```bash
70set -euo pipefail
71echo "=== Exa Pre-Flight ==="
72
73# 1. Verify production API key works
74HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" \
75 -X POST https://api.exa.ai/search \
76 -H "x-api-key: $EXA_API_KEY_PROD" \
77 -H "Content-Type: application/json" \
78 -d '{"query":"pre-flight check","numResults":1}')
79echo "API Status: $HTTP_CODE"
80[ "$HTTP_CODE" = "200" ] || { echo "FAIL: API key invalid"; exit 1; }
81
82# 2. Verify tests pass
83npm test || { echo "FAIL: Tests failing"; exit 1; }
84
85echo "Pre-flight PASSED"
86```
87
88### Step 2: Health Check Endpoint
89
90```typescript
91import Exa from "exa-js";
92
93const exa = new Exa(process.env.EXA_API_KEY);
94
95app.get("/health/exa", async (_req, res) => {
96 const start = performance.now();
97 try {
98 const result = await exa.search("health check", { numResults: 1 });
99 const latencyMs = Math.round(performance.now() - start);
100 res.json({
101 status: "healthy",
102 latencyMs,
103 resultCount: result.results.length,
104 timestamp: new Date().toISOString(),
105 });
106 } catch (err: any) {
107 res.status(503).json({
108 status: "unhealthy",
109 error: err.message,
110 errorCode: err.status,
111 latencyMs: Math.round(performance.now() - start),
112 });
113 }
114});
115```
116
117### Step 3: Gradual Rollout
118
119```bash
120set -euo pipefail
121# Deploy canary (10% traffic)
122kubectl apply -f k8s/production.yaml
123kubectl rollout pause deployment/exa-service
124
125echo "Canary deployed. Monitor for 10 minutes..."
126echo "Check: /health/exa endpoint, error rates, latency"
127
128# After monitoring, resume to full rollout
129# kubectl rollout resume deployment/exa-service
130```
131
132## Post-Deployment Verification
133
134```bash
135set -euo pipefail
136# Verify production endpoint
137curl -sf https://your-app.com/health/exa | python3 -m json.tool
138
139# Check error rates (if Prometheus available)
140curl -s "localhost:9090/api/v1/query?query=rate(exa_search_error[5m])" 2>/dev/null
141```
142
143## Rollback Procedure
144
145```bash
146set -euo pipefail
147# Immediate rollback
148kubectl rollout undo deployment/exa-service
149kubectl rollout status deployment/exa-service
150echo "Rollback complete. Verify /health/exa endpoint."
151```
152
153## Alert Thresholds
154
155| Alert | Condition | Severity |
156|-------|-----------|----------|
157| API Down | 5xx errors > 10/min | P1 |
158| Auth Failure | 401/403 errors > 0 | P1 |
159| Rate Limited | 429 errors > 5/min | P2 |
160| High Latency | P95 > 5000ms | P2 |
161| Budget Warning | Daily searches > 80% of limit | P3 |
162
163## Error Handling
164
165| Issue | Cause | Solution |
166|-------|-------|----------|
167| Health check fails | API key not set in prod | Verify secret injection |
168| Latency spike after deploy | Missing cache warm-up | Pre-populate cache |
169| Rate limit on launch | Traffic spike | Enable request queue |
170| Rollback needed | Error rate spike | `kubectl rollout undo` |
171
172## Resources
173
174- [Exa API Documentation](https://docs.exa.ai)
175- [Exa Error Codes](https://docs.exa.ai/reference/error-codes)
176
177## Next Steps
178
179For version upgrades, see `exa-upgrade-migration`. For incident response, see `exa-incident-runbook`.