Launch checklist
Seven checkpoints, from setup to review.
Select the right organization and event before you change settings. Saving a draft or branding does not publish it. The dashboard’s Launch guide covers the same steps.
Seven checkpoints before, during and after a sale.
-
Connect your hostname
Your hostname is verified and ready for a staging check.
- Hosted: we connect your room; you add the tag and allow its address in your Content-Security-Policy.
- Complete the hostname ownership challenge and configure matching signing keys for that hostname.
- Own Cloudflare zone only: install the Worker with config storage, room authority, rate limiter and telemetry bindings.
- Own Cloudflare zone only: route the waiting runtime and your protected paths to the same Worker. A health response alone does not prove admission works.
-
Prepare the event
The event names the hostname, protected path, sale window and timezone.
- Check the organization and event before editing.
- Use one active room per hostname and check the generated route instructions.
- Keep the draft separate from the last version the QueueRoom Worker acknowledged.
-
Review admission policy
Admission rate, active-session cap, session duration and queue order are understood before you publish.
- A queued buyer is admitted only when a rate permit is due and an active-session slot is free. A rate of zero stops new admissions; a full room does not use up permits.
- New admissions get fixed-length sessions. Changing session duration does not extend sessions already granted.
- Queue rules shows the cap and session duration as read-only. Review rate changes with Admission rate on the Live control tab.
- Queue order is first-come, or a seeded draw for people who arrive before the sale opens. Queue order is not weighted by bot risk.
- Rehearse on the Worker you will use for the sale. Local checks do not prove production capacity.
-
Preview and save branding
The room has reviewed copy and style for its waiting page.
- Open the launch’s Waiting page tab and preview desktop and mobile states.
- Presets change appearance. Check event copy, support details, contrast and motion.
- Save room settings, then stage and review the publication. Stage again if branding changed after staging. An editor preview does not prove what buyers are served.
-
Review and confirm publication
A reviewed change has a receipt from the QueueRoom Worker and a checked buyer flow.
- For a new change, stage it, compare saved and proposed values, and confirm with the slide-to-confirm control. Retrying a failed saved policy happens immediately, as described in Troubleshooting.
- Compare the desired and acknowledged versions. If the receipt is pending or unknown, reconcile the Worker’s status before you publish again.
- Check a fresh buyer request through registration, waiting, admission and your origin. Check the served branding and record how you would roll back.
-
Monitor admission
Operators use current receipts and telemetry to decide whether a change is needed.
- Check the selected event, the publication receipt and how fresh the signals are before tuning.
- Inspect pending visitors, live sessions and recent admissions. Missing data is unknown, not zero.
- Stage and review emergency changes. Rate and cap limits still apply. Waiting browsers pick up policy changes on their next status check.
- Start immediate non-FIFO admission lets waiting buyers in without queue order or pacing, still within the active-session cap. Queue everyone holds every new admission; admitted sessions continue until they expire.
- If the edge still serves an old policy, Purge edge config cache makes the next request load the latest published version. Visitors keep their place.
-
Review the event
Recorded actions and available reports support the next rehearsal.1
- Check the report’s time range and allow for late telemetry.
- Read audit entries alongside publication receipts.
- Write down changes for the next launch.
Something not working?
The setup guide covers installation, troubleshooting and integrations.