Launch verification and routine maintenance

After the deployment script finishes, verify the flows that users will actually follow in production. Create a new test account in the production environment for these checks. Do not assume that local accounts and test orders already exist in the remote database.

Choose checks according to your feature switches. You do not need to temporarily enable unused OAuth, blog, affiliate, or paid features, but pages should not offer unavailable options either.

1. Record the verification environment

Record the production URL, code version, deployment time, and test account. For payment checks, also record whether Stripe is in test or live mode and the corresponding connection ID.

For the initial launch, complete every applicable check in the table below. Subsequent updates can focus on affected features while retaining basic checks for the homepage, sign-in, and core business flows.

2. Verify user flows

If you followed the saved-links tutorial, use two accounts to create and query saved links, confirming user isolation. If you followed WebpageToPDF, check conversion and quota rules for anonymous visitors, registered users, and Pro users as described in the tutorial.

Do not rely solely on the success message shown to the user. Read the result after a write operation. For asynchronous jobs, also check execution status.

3. Verify payments and entitlements

First test Checkout, webhooks, purchase records, and entitlement grants with separate test configuration and data. Verification on the production site uses production configuration. Do not switch only the Secret Key while retaining test Prices or a test endpoint's signing secret.

Check the following in order:

1. The purchase option selects the correct product and Plan, and the displayed price matches the payment page.
2. Returning after canceling payment does not grant entitlements based on the return URL.
3. After successful payment, check order or subscription records and subsequent entitlement state.
4. Call the protected business feature to confirm that permissions or quotas have taken effect.
5. Open the Billing Portal and confirm that it manages the current user's customer and subscription.
6. In the test environment, verify relevant states such as period end, cancellation, failed payments, and refunds.

Scheduling cancellation at the end of a billing period does not immediately remove all entitlements. Determine access from the subscription's validity period and entitlement sources. A refund likewise does not mean that all permissions have been revoked automatically. Verification results should match your product's actual refund rules.

Purchases in live mode create real transactions. If you need to verify a live transaction, follow your own payment and refund arrangements and record the order. Do not use test cards or treat test transaction results as proof of live-mode verification.

If the payment platform received funds but website entitlements have not changed, first check webhook delivery, signature verification, payment synchronization, and Reaction execution, then the plan's access configuration. Do not ask users to pay repeatedly to trigger a fix.

4. Verify files, support tickets, and background jobs

Complete the following for enabled features:

• Upload a test image or business file, then read it through the returned URL to confirm that production storage is being used.
• Create a support ticket as a regular user, then read and reply to it as an administrator. Confirm that its status and attachments work.
• Generate a visit on a public page, then check whether analytics data appears in the admin dashboard.
• Trigger a normal business event and check the Reaction Event and Command execution results.
• Inspect queue consumption, retries, or backlogs, along with Cron configuration and execution logs.

You can view Reaction records through the corresponding admin dashboard pages, for example:

/dashboard/reaction/events
/dashboard/reaction/commands

A queue accepting a message only confirms that it was enqueued. A successful Cron trigger only confirms that its entry point was called. Check Command execution records and business data for the final result, rather than relying only on trigger counts.

Analytics data may be processed asynchronously through a queue. Do not immediately assume collection failed after refreshing the page. Check requests, queues, and the analytics database along the flow described in Analytics. For other background flows, see Background jobs and Scheduled tasks.

5. What to monitor after launch

Once the site is open to users, prioritize signals that block user flows:

To view live Worker logs, run this from the project root:

npx wrangler tail

Review these alongside Worker, Queue, and D1 status in Cloudflare and logs in the site's admin dashboard. When sharing troubleshooting information, retain request, event, and order identifiers, but hide tokens, signing secrets, and unrelated user data.

If notification channels are configured, you can send important business failures to a destination that someone actually monitors. See Notifications for configuration. Verify delivery rather than merely creating the destination.

6. Troubleshoot common problems

The homepage works, but signup fails

First check Turnstile and email configuration, then the database and Reaction. The homepage usually does not exercise all these modules, so a working homepage does not prove that signup dependencies are ready.

OAuth returns to the wrong URL or redirects repeatedly

Check the production VITE_SITE_URL, allowed application hosts, the application associated with the OAuth Client ID, and the Callback URL saved on the platform. Confirm that the browser did not enter through an old origin and that no language path was added to the API callback.

Payment succeeds, but backend state does not update

First check whether the event reached the production endpoint and whether the signing secret belongs to that endpoint, then check synchronization and subsequent Commands. Once the cause of failure is fixed, use the provider's or project's existing retry mechanism and verify that it does not produce duplicate business results.

Documentation or blog pages return 404

First confirm that the feature is enabled and that the article exists in the requested language, then check MAIN_KV and synchronization output. If an article was deleted but remains in the sidebar, check meta.json as well. Rebuilding only the homepage is not enough.

The database reports no such table or no such column

Confirm that the failing request's binding and the migration operation point to the same database, then inspect migration records and actual fields. Do not reset production to restore access, or manually repair remote tables without adding the corresponding migration files.

7. Recover from a failed release

First assess the scope of the impact. If necessary, pause affected purchase or business entry points, then preserve error logs, event states, and release records. Prioritize the specific failed step and avoid changing unrelated modules at the same time.

Before rolling back to an older Worker version, confirm that it can still read the current database schema and data formats. A Worker rollback does not restore D1, KV, or R2 content. Binding changes and Durable Object migrations may also limit rollback. See Cloudflare's rollback documentation for the specific conditions.

Database restoration is a separate operation. Evaluate it using the records prepared in Production databases and content. Restoring to an earlier point in time does not automatically rewind the payment platform, emails, sent notifications, or consumed queue messages. Reconcile them separately.

For example, if a payment succeeded but the database was restored to a point before payment, the disappearance of the local order does not mean the transaction never happened. Use payment platform records and the project's idempotent processing mechanisms to reconcile and compensate for the difference.

8. Carry verification results forward to the next release

Keep a short record of the version, changes, migration and configuration updates, completed verification checks, and features not yet enabled. Use it during subsequent updates to identify behavior that must remain unchanged.

Continue using npm run deploy:update for routine updates. See Development recipes for adding business features and Features for adjusting built-in modules. Periodically test whether backups can be restored and notifications reach someone, rather than relying only on stored configuration.