Rotate a bot token with a deployment checklist

Replacing a bot token is not complete when one environment variable changes. A second deployment, an old configuration file or a copied diagnostic message may still hold the previous secret.

Plan the rotation around every place the bot runs and every place the credential has been stored.

Identify the active deployments

List production, staging, local development and any scheduled or standby process. Decide which deployments should continue to have access and which should be retired.

Use the platform's supported token-management procedure. Do not assume that a library-level reconnect creates a new credential or revokes the old one.

Prepare the change

Keep the new value out of public repositories, screenshots and command transcripts. Update the appropriate secret store or protected environment setting, then restart or redeploy the process as required by its runtime.

A setting saved in a dashboard does not prove that an already running process has loaded it.

Verify useful behaviour

Test a representative event and action with the correct account or test community. Watch for authentication failures and duplicate processes responding at once.

Record the time the new credential was deployed and the point at which the old one was revoked. If rotation is responding to a suspected exposure, review what the old credential could access as well.

Remove residual copies

Check example files, exported configurations, support attachments and local notes for accidental copies. If a token was committed to a repository, deleting the visible line is not the same as removing every historical copy; treat the exposed credential as needing revocation.

Use the Discord secrets guide or Telegram secrets guide for the relevant service. A short inventory makes the next rotation much less uncertain.