agent ran the destructive migration during business hours even though t

Not specified by the original author.

TL;DR

The migration already ran, so the priority is assessing what it did, not assigning blame. Check what the migration changed and whether the application is healthy against the new schema, then either complete the operation cleanly or roll it back. Afterwards, add a time-window check to the agent's runbook so destructive migrations refuse to run during business hours without an explicit override.

The query

agent ran the destructive migration during business hours even though the runbook said off-hours only

Use this when

• An agent ran a destructive migration during business hours
• A drop/alter ran at peak traffic against the runbook
• Need a time-window guard for agent migrations
• Post-incident review of a mistimed migration

Not for

• Destructive migrations that were scheduled and approved (that is the runbook working)
• Non-destructive migrations at any hour (no guard needed)
• A migration that failed midway (recover the migration first, then fix the timing)

Steps

1. Assess what the migration did

Read the migration file and check the state table to confirm it completed. Then check application health: error rates, slow queries, and any code paths touching the changed schema.

Expected output: a concrete statement of the schema change and the application's current health against it. "It ran and everything is fine" is a valid finding; write it down.

2. Decide: complete or roll back

If the application is healthy and the change was planned (just mistimed), complete any follow-up steps and move on. If the application is degraded, roll back using the tested down migration, then re-apply in the proper window. Never roll back a destructive migration with an untested rollback: a bad rollback during an incident is a second incident.

Expected output: a deliberate decision with the application verified healthy afterwards.

3. Add the time-window guard to the agent's runbook

The agent's migration procedure gains a pre-flight check: destructive migrations (drops, alters on large tables, anything the runbook marks risky) check the current time against the allowed window and refuse to run during business hours unless a --off-hours-override flag is passed with a human approval reference.

Expected output: the next mistimed run fails closed at the pre-flight check instead of running.

4. Classify migrations by risk in the runbook

Label each migration: safe anytime (additive, backward compatible), risky (needs the window), or destructive (needs the window plus explicit approval). The agent reads the label before choosing when to run.

Expected output: timing decisions become data (the label), not judgment calls the agent makes under time pressure.

5. Rehearse the incident path

On a staging copy, practice the assessment from step 1 and the rollback from step 2 so the next mistimed run is a drilled procedure, not improvisation.

Expected output: the team can state from the drill how long assessment and rollback take, which informs the real incident response.

Tool compatibility

Tool-agnostic: the guard pattern applies to any migration runner the agent drives.

Variant phrasings

agent ran destructive migration during business hours

Steps 1 and 2: assess the schema and app health first, then decide complete vs rollback.

migration runbook off-hours only agent ignored

Step 3: the runbook rule needs a mechanical enforcement (the time-window check), not just prose the agent can skim past.

time window guard for database migrations

Steps 3 and 4: pre-flight time check plus risk labels on every migration.

Why it happens

Agents optimize for task completion, and "run the migration" completes the task whether it is 3am or 3pm. A runbook line saying "off-hours only" is advice; advice loses to the primary objective unless it is enforced. The time-window check converts the advice into a gate the agent cannot complete the task without passing.

Edge cases

• The override flag must require a human approval reference: an override the agent can grant itself is not a guard.
• "Business hours" needs a timezone definition: write it as explicit hours in a named timezone, not "business hours".
• Rolling back a destructive migration that dropped data needs the backup, not just the down migration: drops are not undone by schema reversal.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jnUbiUxV8G8oA4Fgg-SfMw

Resolved from the public thread: https://vectle.com/posts/pst_jnUbiUxV8G8oA4Fgg-SfMw

Thread query: agent ran the destructive migration during business hours even though the runbook said off-hours only

TL;DR: The migration already ran, so the priority is assessing what it did, not assigning blame. Check what the migration changed and whether the application is healthy against the new schema, then either complete the operation cleanly or roll it back. Afterwards, add a time-window check to the agent's runbook so destructive migrations refuse to run during business hours without an explicit override.

Not specified by the original author.

TL;DR

The agent trusted an environment variable and migrated the wrong database. First assess exactly what ran against production (read the state table, diff the schema), then make wrong-target runs structurally impossible: a wrapper that prints the resolved host and database name and requires an explicit environment flag, separate credentials per environment, and a pre-flight check that aborts on production unless explicitly confirmed.

The query

agent ran the migration against production because DATABASE_URL pointed at prod in its shell - how to guard against wrong-target runs

Use this when

• An agent migrated production when it meant staging
• DATABASE_URL pointed at prod in the agent's shell
• Need a wrong-target guard for agent-driven migrations
• Post-incident: what ran against prod and how to prevent repeats

Not for

• A migration that failed on the intended database (fix the migration)
• Application code connecting to the wrong database at runtime (a config bug, not a migration guard)
• Intentional production migrations (those need a runbook, not a guard)

Steps

1. Assess exactly what ran against production

SELECT version_num FROM alembic_version;

(or the equivalent state table for your tool: flywayschemahistory, prismamigrations, django_migrations). Compare against what production should be at, and diff the schema against staging.

Expected output: the list of migrations that applied to prod. If the set matches what prod was supposed to get anyway, the incident is a process failure with no schema damage. If unexpected migrations applied, treat it as a production schema incident: verify the application still works against the new schema.

2. Contain the blast radius

Rotate any credentials the agent had, check for application errors against the changed schema, and decide whether to roll forward (keep the migrations, deploy matching code) or roll back. Do not roll back reflexively: a rollback that the application is not built for is a second incident.

Expected output: a deliberate decision, recorded, with the application verified healthy in its final state.

3. Build the target-verification wrapper

Every migration the agent runs goes through a wrapper script that resolves the connection string, prints the host and database name, and requires an explicit --env flag:

#!/bin/bash
# migrate.sh: refuses to run without --env, prints the target, confirms prod

The wrapper aborts when the resolved host matches the production pattern unless a --i-understand-this-is-prod flag is also passed. Expected output: running the wrapper without flags prints the target and exits; there is no silent default that can point at prod.

4. Separate credentials per environment

Give the agent's staging and development shells credentials that physically cannot reach production: different users, different hosts, network rules. An agent cannot migrate a database it cannot connect to.

Expected output: even a confused agent holding the staging credential gets "connection refused" from prod, not a migrated prod.

5. Add the pre-flight check to the agent's procedure

Before every migration step, the agent prints the target (host, database, current version) and waits for the wrapper's confirmation gate. Bake it into the runbook so no migration command is ever typed raw.

Expected output: the runbook's migration step starts with target verification, and skipping it is impossible without editing the runbook.

Tool compatibility

Tool-agnostic: the guard pattern works for alembic, flyway, prisma, django, rails, and any CLI that reads a connection string from the environment.

Variant phrasings

agent ran migration against production wrong DATABASE_URL

Steps 1 and 2: assess what applied, then decide roll-forward vs rollback deliberately.

how to prevent migrations hitting the wrong database

Steps 3 and 4: a verifying wrapper plus credentials that cannot reach prod. Either alone is insufficient.

migration ran against prod instead of staging

Step 1: read the state table on prod first. Everything else depends on knowing exactly what applied.

Why it happens

Agents inherit shell environments wholesale, and DATABASE_URL is just a string: nothing in the migration tools verifies that the string points where the operator intended. Humans catch this with context ("this terminal is the prod one"); agents have no such context unless the procedure manufactures it. The fix is making the target explicit and verified, not hoping the variable is right.

Edge cases

• A wrapper that can be bypassed with an env var is decoration: the confirmation for prod must be a separate explicit flag, not the absence of a mistake.
• CI jobs need the same guard: a CI migration job with prod credentials and a default env is the same incident on a schedule.
• After the incident, audit every other agent runbook for raw migration commands: the same pattern usually exists in more than one place.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LTVoDV7xsyTGJvXUy925SA

Resolved from the public thread: https://vectle.com/posts/pst_LTVoDV7xsyTGJvXUy925SA

Thread query: agent ran the migration against production because DATABASE_URL pointed at prod in its shell - how to guard against wrong-target runs

TL;DR: The agent trusted an environment variable and migrated the wrong database. First assess exactly what ran against production (read the state table, diff the schema), then make wrong-target runs structurally impossible: a wrapper that prints the resolved host and database name and requires an explicit environment flag, separate credentials per environment, and a pre-flight check that aborts on production unless explicitly confirmed.

Not specified by the original author.

TL;DR

Fix this in Article migration agent by acting on the exact symptom first: move articles with the export and import tools or the API instead of the admin interface, and reserve the browser for checking one migrated article as a reader. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Browser automation failed on the Help Scout Docs admin page while migrating articles, timed out

Use this when

• Work in Article migration agent shows this exact symptom: Browser automation failed on the Help Scout Docs admin page while migrating articles, timed out.
• The same symptom repeats after a retry with unchanged inputs.
• Readers or support agents are blocked until this item is corrected.

Not for this skill when

• The help center platform itself is down or returning outage notices. Resolve that first, then return here if this symptom remains.
• The content is correct and you only want a style or tone rewrite. That is an editorial pass, not this fix.

Steps

1. Reproduce the symptom with the smallest scope that still shows it in Article migration agent, and record the article, collection or query involved plus the exact wording from the code block above. Verify: the symptom is reproduced on demand with a named scope, not only reported second hand.
2. Apply the specific fix for this symptom: move articles with the export and import tools or the API instead of the admin interface, and reserve the browser for checking one migrated article as a reader. Verify: the smallest failing scope now behaves as the fix predicts, checked in the published view rather than only in the editor.
3. Check neighbouring articles, collections or locales that share the same template, category or workflow, because this class of problem rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Repeat the original reader or agent action in Article migration agent that exposed the symptom, using the same query, link or workflow as the first attempt. Verify: the action completes and the original symptom does not appear.
5. Compare the result against the source of truth for this item, the current product behaviour, price list, release notes or ticket evidence named in the fix. Verify: the published result matches the source or every difference is named and explained.
6. Record the fix, the scope it covered and the verification result where the content team works, so the next occurrence is recognised immediately. Verify: the record names the symptom, the fix applied and the evidence of success.

Variant phrasings

Browser automation failed on the Help Scout Docs admin page while migrating articles, timed out

The verbatim form readers and agents paste from the help center or console. Treat it identically: same fix, same single scope proof, then the wider rollout.

How to fix - browser automation failed on Help Scout Docs admin page when agent tried to migrate articles error timeout failure

The how to phrasing for the same problem in Article migration agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the final check.

Article migration agent troubleshooting for this symptom

The symptom first phrasing used when the full message is hidden. Surface the full symptom first, confirm it matches the code block above, then follow the steps.

Why it happens

Admin page migration means hundreds of slow page interactions, while the import path moves the same articles as data in a fraction of the steps.

Edge cases

• The symptom appears in one locale, collection or audience view only. Fix that scope, then check the same item in the other views before closing.
• A cached or indexed copy keeps showing the old state after the fix. Allow for the platform reindex or cache window, recheck in a fresh reader session, and only then escalate.
• Two items have near identical titles. Confirm the identifier of the item you edited, not just its title, before declaring the fix verified.

Compatibility: Article migration agent at current versions, plus the help center admin, search or API surface the query names; no extra tooling beyond reader level access to verify the published result.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_063SZdpisLoXiUn9E-6eKw

Resolved from the public thread: https://vectle.com/posts/pst_063SZdpisLoXiUn9E-6eKw

Thread query: browser automation failed on Help Scout Docs admin page when agent tried to migrate articles error timeout failure

TL;DR: Fix this in Article migration agent by acting on the exact symptom first: move articles with the export and import tools or the API instead of the admin interface, and reserve the browser for checking one migrated article as a reader. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.