---
summary: Go-live guidance for SigID business owners covering billing, support, launch checks, secrets, domains, monitoring, and rollback planning.
tags:
  - business
  - production
  - billing
  - checklist
categories:
  - For Business
---

# Go Live

<!-- agent:page
You are an AI agent helping a business owner take a SigID workspace live: billing, support, domains, secrets, sign-off, and rollback.
Ask up front: which workspace and application are launching, who the billing owner and launch owner are, the production domains with exact redirect URLs and allowed origins, which login methods and SSO connections are in use, and whether webhooks are used.
Flow: work through every row of the Production Checklist (Billing, Support, Domains, Branding, Login methods, Secrets, Tokens, Webhooks, SSO, Audit, Recovery), then run the Launch Sign-Off tests as each audience (individual user, business operator, developer, SSO user, support), then document the Rollback Plan. Verify configuration in the Dashboard at dashboard.sigid.org.
Do not treat sign-in as ready until users can start in the real app, complete SigID sign-in, and return to the app.
Success: every checklist row passes, all applicable sign-off tests pass, and a rollback plan covers sign-in methods, redirect URLs, SSO, branding, scopes, webhooks, and token validation.
Pitfalls: treating sign-in as ready without the real-app round trip, and launching with no rollback plan for redirect URL or SSO mistakes.
Billing plan and invoicing confirmation and final launch approval are human decisions; you verify checklist items, run the tests you can, and draft the rollback plan for review.
-->

Use this page before real users depend on your SigID workspace.

Going live means the business settings, support process, and developer
integration are ready together. Do not treat sign-in as ready until users can
start in the real app, complete SigID sign-in, and return to the app.

## Production Checklist

<!-- agent:action Work the production checklist
Verify each row: Billing (owner, plan, invoicing path confirmed), Support (users know where to get help for login, recovery, and account questions), Domains (production domains, redirect URLs, and allowed origins registered exactly), Branding (name, logo, consent prompts users recognize), Login methods (every enabled choice tested), Secrets (client and webhook secrets outside browser code), Tokens (backend validation checks issuer, audience, tenant, expiry, scopes, and subject type), Webhooks (signature verification and safe retries, if used), SSO (enterprise login and fallback tested, if used), Audit (operators can review important events), Recovery (expectations documented).
Billing confirmation requires the human billing owner - flag it for them rather than checking it yourself.
Report any unverified row as a launch blocker.
-->

| Area | Check |
|---|---|
| Billing | Billing owner, plan, and invoicing path are confirmed. |
| Support | Users know where to get help for login, recovery, and account questions. |
| Domains | Production domains, redirect URLs, and allowed origins are registered exactly. |
| Branding | App name, logo, and consent prompts match what users recognize. |
| Login methods | Passkeys, passwords, magic links, MFA, and SSO choices are tested. |
| Secrets | Client secrets and webhook secrets are stored outside browser code. |
| Tokens | Developers confirm backend token validation checks issuer, audience, tenant, expiry, scopes, and subject type. |
| Webhooks | Receivers verify signatures and handle retries safely, if events are used. |
| SSO | Enterprise login and fallback process are tested, if SSO is used. |
| Audit | Operators can review important identity and access events. |
| Recovery | Account recovery expectations are documented. |

## Launch Sign-Off

<!-- agent:action Run launch sign-off tests
Run one complete test as each audience: an individual starts from the app, signs in with SigID, and returns to the app; a business operator updates a user, app, or organization setting; a developer verifies the backend rejects an invalid token; an SSO user completes SSO, if applicable; support explains what to do when login or recovery fails.
Every applicable test must pass - a single failure blocks sign-off.
Final sign-off is the launch owner's decision; present them the results.
-->

Before launch, run one complete test as each audience:

- an individual starts from the app, signs in with SigID, and returns to the app
- a business operator updates a user, app, or organization setting
- a developer verifies the backend rejects an invalid token
- an SSO user completes SSO, if applicable
- support can explain what to do when login or recovery fails

## Rollback Plan

<!-- agent:action Prepare the rollback plan
Draft a rollback plan covering each listed area: sign-in method changes, redirect URL mistakes, SSO misconfiguration, app branding mistakes, bad scopes or consent prompts, webhook receiver failures, and backend token validation errors.
Include the user message: if launch fails, users return to the original app or support channel instead of trying random SigID links.
Have the launch owner review and approve the plan before go-live.
-->

Keep a rollback plan for:

- sign-in method changes
- redirect URL mistakes
- SSO misconfiguration
- app branding mistakes
- bad scopes or consent prompts
- webhook receiver failures
- backend token validation errors

If launch fails, tell users to return to the original app or support channel
instead of trying random SigID links.