## TL;DR

"Read replica" does not mean "safe to hammer." Replicas serve real workloads like BI and analytics, and a stress test saturates the same CPU and IO those queries need. Stop the test, confirm the affected team recovered, move testing to an isolated target, and make target-ownership verification a mandatory pre-flight step.

## The query

```text
agent ran a stress test against the production read replica the analytics team was using and paged them
```

## Steps

### 1. Stop the test and confirm recovery

Halt the stress run immediately. Check with the affected team that their queries are completing normally again, and watch the replica's lag and resource metrics return to baseline.

Expected: replica metrics back to normal, affected team confirms their work is unblocked.

### 2. Inventory who uses the target

List everything consuming the replica you hit: BI dashboards, scheduled reports, ad-hoc analysts, other services. Check connection sources on the replica during a normal window.

Expected: a concrete list of consumers that explains exactly who got paged and why.

### 3. Move the test to an isolated target

Options in order of preference: a dedicated test replica that serves nothing else, a restored snapshot of production data on throwaway infrastructure, or a staging clone. The key property is that no other team depends on it.

Expected: a test target with zero external consumers, verified by checking its connection sources.

### 4. Add target-ownership pre-flight to the agent's workflow

Before any load or stress test, the agent must: resolve the target to concrete infrastructure, list its consumers, and confirm the target is on an explicit allowlist of test-owned resources. Shared production infrastructure is never an allowed target without written sign-off from its owners.

Expected: a checklist the agent cannot skip, with the allowlist stored where the agent reads it.

### 5. Apologize with the fix, not just words

Tell the affected team what happened, what changed in the workflow, and where the new guardrail lives. People forgive incidents faster when the prevention is concrete.

Expected: the team knows the repeat is structurally prevented, not just promised.

## Use this when

- A test hit infrastructure another team depends on
- The target was assumed safe because it was "just a replica"
- The agent picked the target from a connection string without checking ownership
- You need a pre-flight checklist for test targeting

## Not for this skill when

- The target was already isolated and the problem was pool sizing or bad traffic
- The disruption came from replaying side-effecting traffic (webhooks, charges)
- The replica lag itself is the production problem being investigated
- The test ran in a fully isolated perf environment

## Variant phrasings

### load test paged another team

Same recovery: stop, inventory consumers, isolate the target, add the checklist.

### stress test on shared replica

Replicas are production. Treat them as production in the test plan.

### agent tested against the wrong database

The fix is target verification before the first request, not after the page.

## Why it happens

Agents pick targets from configuration: a connection string labeled "replica" looks like a safe, production-like test bed. Nothing in the string says who else uses it. The agent optimized for realism (production-like data and shape) and never asked the ownership question, because its planning model had no step for it. The label described the topology, not the sharing.

## Edge cases

- Even isolated replicas share the writer's write-ahead log stream: extreme write load on the writer can still lag a test replica. Isolated does not mean fully independent.
- Snapshot restores lag reality: data may be hours old, which is fine for load shape but not for freshness-sensitive tests.
- DNS or service discovery pointing at the wrong target: verify the resolved address, not just the hostname, in pre-flight.
- Analytics teams sometimes run on the writer during incidents: re-verify consumers periodically, not once.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jB7w-21DTir8eJfLwFGAEQ