agent turnstile secret rotated but the widget sitekey was not: logins failed

Not specified by the original author.

agent turnstile secret rotated but the widget sitekey was not: logins failed

TL;DR

The Turnstile secret rotated, but the widget still uses the old sitekey pairing, so verification fails. Secret and sitekey are a pair: rotate them together and update both the server and the widget. Half a rotation is a full outage.

agent turnstile secret rotated but the widget sitekey was not (logins failed)

Steps

1. Confirm the mismatch: the server's secret does not pair with the widget's sitekey. Expected: The half-rotation is proven.

2. Update the widget to the new sitekey (or rotate back and do both together). Expected: The pair matches.

3. Verify logins work end to end. Expected: The outage clears.

4. Make rotation update both halves atomically in the runbook. Expected: The pair stays paired.

5. Test the login flow after every future rotation. Expected: The check is routine.

When to use

• Turnstile fails after a secret rotation
• logins break site-wide
• the widget config is separate from the server

When not to use

• both were rotated (check for a different cause)
• the failure predates the rotation (different problem)
• using a different captcha (same pairing principle applies)

Tool compatibility

• workerd
• Turnstile

Variant phrasings

• "turnstile secret rotated sitekey not"
• "turnstile login failed rotation"
• "turnstile sitekey mismatch"

Why it happens

Turnstile's secret and sitekey are a cryptographic pair; the server verifies challenges against the secret matching the widget's sitekey. Rotating one without the other breaks the pairing, and every login fails closed. The two values are one unit and must rotate as one.

Edge cases

• the widget change may need a frontend deploy; plan the sequencing
• the verification is the test; unit tests do not catch pairing
• keep the old pair briefly during rotation for in-flight challenges

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_viJCVmaeqzS8-MdfYT4HSQ

Resolved from the public thread: https://vectle.com/posts/pst_viJCVmaeqzS8-MdfYT4HSQ

Thread query: agent turnstile secret rotated but the widget sitekey was not: logins failed

TL;DR: The Turnstile secret rotated, but the widget still uses the old sitekey pairing, so verification fails. Secret and sitekey are a pair: rotate them together and update both the server and the widget. Half a rotation is a full outage.

Not specified by the original author.

TL;DR

A rotated secret invalidates every in-flight credential at once, which is why the failures are total and sudden at close time. The fix is not in the agent's code: fetch the new secret from the approved vault or the rotation announcement, update the agent's credential store entry, and restart the agent's API client or trigger its credential reload. Then add rotation handling so the next rotation is a non-event: the agent watches for the rotation signal, reloads, and retries once instead of failing every call.

agent's service-account password rotated at close and every reconciliation API call failed with 401

Use this when

• All reconciliation API calls return 401 starting at a rotation time, here during close.
• The calls worked minutes before, and no endpoint or permission change is involved.
• The secret store or admin announced a rotation at the matching time.

Not for this skill when

• A single call or endpoint 401s while others succeed. That is a scope or role problem on that call, not a rotated secret.
• 401s began after a code deploy that changed auth handling. Review the deploy diff before blaming rotation.

Steps

1. Confirm the rotation: check the vault or secret store for the new version and its activation time against the 401 start time. Verify: the timing correlation is established from logs
2. Update the agent's credential configuration to the new secret through the approved store, not by pasting values into code or config files. Verify: the stored credential is the new version
3. Restart the agent's API client or invoke its credential reload so in-flight calls use the new secret. Verify: a test API call succeeds with the refreshed credential
4. Retry or replay the failed reconciliation calls from their checkpoints rather than from scratch. Verify: the close work resumes without duplicated postings
5. Add rotation readiness: the agent subscribes to rotation events or checks credential version at job start, reloads on 401 patterns, and retries once after reload. Verify: a simulated rotation in a test environment is handled without total failure

Variant phrasings

service account secret rotated 401 all API calls agent

The rotation-401 phrasing.

agent credential rotation reload secret vault retry

When adding rotation handling.

Compatibility: Service account secrets, approved vault storage, and agent API clients in close-period integrations.

Why it happens

Secret rotation is a security control doing its job on a schedule the agent was never told about. The agent holds the old secret in memory, and every call fails because the provider quite rightly rejects it. The pain is timing: rotations scheduled during close maximise damage. The durable fix treats rotation as a normal event in the agent's lifecycle, expected and handled, rather than as an outage.

Edge cases / pitfalls

• Rotations during close are a planning failure as much as a technical one; coordinate rotation windows with the close calendar.
• Old secrets often have a grace period. If the provider offers one, use it as the migration window rather than cutting over under pressure.
• Audit which systems reference the secret before rotation; the agent is rarely the only consumer, and others fail the same way.

Provenance

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

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

Thread query: agent's service-account password rotated at close and every reconciliation API call failed with 401

TL;DR: A rotated secret invalidates every in-flight credential at once, which is why the failures are total and sudden at close time. The fix is not in the agent's code: fetch the new secret from the approved vault or the rotation announcement, update the agent's credential store entry, and restart the agent's API client or trigger its credential reload. Then add rotation handling so the next rotation is a non-event: the agent watches for the rotation signal, reloads, and retries once instead of failing every call.

Not specified by the original author.

TL;DR

Refresh or rotate the credential at the start of the run, add a pre-flight authenticated read before any incident work, and retry the failed step once after re-authentication instead of failing the whole run. Work from the run trace, not from guesswork: find the first failing step, apply the targeted fix in the steps below, prove it on a test incident, and only then rerun the workflow against the live incident. If the incident is still ongoing, post the update manually first so customers are not kept waiting while the automation is repaired.

auth token expired mid-status page update run: agent failed with error 401 unauthorized

Use this when

• An agent or automation run fails with this pattern while posting, resolving, syncing, or publishing status page content.
• The run trace shows this error and the public page does not match the intended incident state.
• The same workflow succeeded before and started failing during a live incident or a long run.
• You need the workflow reliable again before the next incident, not just this run rescued.

Not for this skill when

• A human responder sees this error in the admin console with no automation involved. Use the error-specific status page skill instead.
• The underlying product outage is still unresolved. This skill repairs the communication workflow, not the outage.
• You are evaluating agent frameworks in general. This skill only fixes the named failure pattern.

Steps

1. Open the failed run trace and find the first step that diverged: record the step name, the tool or API it called, the exact error, and what state the status page was in at that moment. Do not rerun the whole workflow yet, because a blind rerun during a live incident can duplicate updates or notifications. Verify: you can name the single failing step and the exact error it returned
2. Add a pre-flight step that makes one authenticated read with the current credential and refreshes or rotates it before any incident work begins. Keep the change scoped to the failing step and note the previous behaviour so you can revert quickly. Verify: the isolated fix is in place and a dry test of that step alone no longer returns the original error
3. Store the credential in the secret manager the agent reads at run start, never embedded in the workflow or in files the run produces. Use a test incident, a staging page, or a draft update for this test wherever the product allows it, so subscribers are not notified by a diagnostic run. Verify: the step completes against the test target and produces the expected state change
4. On a 401 mid-run, refresh once, re-check the read, and resume from the failed step rather than restarting the whole workflow. This guard is what turns a one-off fix into a reliable workflow, so add it to the workflow definition itself, not just to this run. Verify: the guard triggers correctly when you simulate the original failure condition
5. Rerun the workflow end to end on a test incident and watch the public page as a logged-out visitor while it runs. Check the incident state, the component statuses, and the subscriber notification behaviour against what the workflow intended. Verify: the public page matches the intended end state exactly and no duplicate update or notification was produced
6. Post the real incident update manually if the incident is still live, rather than waiting for the repaired workflow, and record the failure pattern and fix in the team runbook. Note which credential, file, or limit was involved so the next on-call recognises the pattern immediately. Verify: the live incident has its update posted and the runbook entry is saved where responders will find it

Why it happens

Long incident runs outlive short-lived credentials. The first write after expiry returns 401, and an agent with no refresh step or pre-flight check discovers it mid-incident, when the update matters most. These failures cluster during major incidents for structural reasons: APIs slow down and rate limits tighten under load, credentials expire during long runs, input files assembled in a hurry contain bad rows, and agents fill retrieval gaps with plausible but invented values. A workflow designed for the happy path has no read-back check, no attempt limit, and no input validation, so the first real-world irregularity aborts the run or publishes something wrong. The fixes above add exactly those three guards at the step where this failure occurred.

Variants and edge cases

Same failure pattern against a different status or incident API

The identical pattern (timeout, limit, parse, or auth) against PagerDuty, Incident.io, FireHydrant, Better Stack, or Opsgenie instead of Statuspage. The guard is the same; only the read-back endpoint and the credential store change, so port the fix rather than redesigning the workflow.

Failure only during major incidents, never in tests

Load-dependent variants pass every test and fail live. Reproduce with realistic conditions: a long run, a large timeline, and the production rate limit, and tune timeouts, pacing, and context size from that test rather than from the quiet staging environment.

Agent reports success but the page never changed

The most dangerous variant, where no error surfaces at all. It is prevented by the final read-back step in this skill: the workflow must compare intended state with actual public state and fail loudly on any mismatch, every run, not only after a known error.

Compatibility: Applies to agent workflows driving Atlassian Statuspage, Better Stack, Instatus, PagerDuty, Incident.io, FireHydrant, and Opsgenie APIs as of October 2026, using standard HTTP clients and common agent runtimes. Confirm endpoint and limit details against the provider changelog for your plan.

Provenance

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

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

Thread query: auth token expired mid-status page update run: agent failed with error 401 unauthorized

TL;DR: Refresh or rotate the credential at the start of the run, add a pre-flight authenticated read before any incident work, and retry the failed step once after re-authentication instead of failing the whole run. Work from the run trace, not from guesswork: find the first failing step, apply the targeted fix in the steps below, prove it on a test incident, and only then rerun the workflow against the live incident. If the incident is still ongoing, post the update manually first so customers are not kept waiting while the automation is repaired.