Stable Queue
SETUP YOUR STABLE
SETUP YOUR STABLE
SETUP YOUR STABLE
Help Guide
Help is already loaded on this page, so you can open it without leaving the screen you were using.
Start Here
Your organization is the main container for your events, admins, promos, queue settings, and retention rules.
Add door staff and trusted helpers to the organization before event day. Do not wait until the line has already formed.
Fill in the event details, capacity, queue type, time zone, invite message, and how many extra guests each attendee may bring.
Open the event, go to Settings, and copy the Telegram posting command. Send that command in the correct room so users can press Check or Join.
Once the event is running, have your on-site admins open that event in the browser and begin scanning people in as they are invited and arrive at the door.
Day Of Event
Working Live
The top bar changes color to show connection health. Green means the event page is syncing well, yellow means there have been recent failures, and red means staff should assume the connection is struggling. The badge also shows how many actions are still waiting to sync.
The event tools are designed to keep working when service is weak. Changes are queued on the phone and retried when the connection comes back, so avoid reloading unless you really need to.
Use Scan for admits, Headcount for manual counts, Stats for a quick room summary, and Settings for operational changes, Telegram posting info, and bulk commands.
Useful Tip
Dangerous Settings
Dangerous settings let the event creator or system admin edit the original event definition. They are powerful, but they do not rewind messages that were already sent.
On-Site Help
On-Site Help
If the room post itself is wrong, you need to update the event and then post a fresh room message.
On-Site Help
Freeze new invites first, warn the people already on the way, then fix the invite text.
On-Site Help
On-Site Help
On-Site Help
On-Site Help
On-Site Help
On-Site Help
On-Site Help
On-Site Help
On-Site Help
On-Site Help
Selection Rules
First in, first out. Users are invited in the same order they joined.
Everyone currently waiting has the same chance each time the system selects a new person.
This mode gives better odds to people who have not already attended events in the same organization. It is useful when you want to favor newer attendees.
This mode gives better odds to people who have attended before. The more prior attended events they have in the organization, the more this can help them.
This mode gives better odds to people with more chatty points in associated rooms. It is meant for communities that want room participation to matter.
This mode looks only at manually awarded and promo-based bonus points. It ignores attendance-history boosts and chatty boosts, so staff-controlled points decide the extra odds.
A weighted queue does not become first-come-first-served. It still picks randomly, but users with more relevant weight get better chances each time the system chooses someone.
Multiplier
Capacity
Queue Timing
Chatty Points
Chatty points only matter if you turn them on for the organization and choose a queue type that uses them.
Admin Commands
Send this in the room where you want people to join. It posts the event card with Check and Join buttons, and it also links that chat to the event.
Reply to a user's message in an associated room to give them bonus points. This is good for one-off recognition, such as helping with setup or donating supplies.
Use this in an associated room to ban someone from the organization. Their active queue entries for that organization will be closed so staff can handle the situation.
Use this in a Telegram room to create or refresh a direct organization link for chatty tracking. This is helpful if an older link expired and the bot asked an admin to reconnect the room.
Important Rule
Attendee Flow
Promo Entry
Associations
If A Link Expires
Quick Tip
Points Basics
Decay
Promos
Manual Awards
Practical Advice
Technical Notice
This notice covers the main categories of data stored in the Stable Queue database, where that data comes from, how the system uses it, and when it is deleted.
The website user account section below applies only to people who sign in to the Stable Queue admin website. Attendees who only interact through Telegram queue flows do not get a normal website user account row unless they also log in to the website.
On-site admin devices may also keep temporary browser local-storage data such as cached event state, queued offline actions, and recent scans. That device-local cache is not part of the main database and can be cleared from the event settings screen.
Stored Category
Taken from the Telegram website login payload when a person signs in to the web admin panel.
Used to create and update admin website accounts, identify organization owners and admins, and connect a Telegram identity to web permissions. This table is not the main attendee queue table.
A website user is scheduled for deletion 24 hours after creation unless that person is a system admin, an organization owner, or an active organization admin. If a person later loses their last owner/admin role, the row is scheduled for deletion 24 hours after that role change. Before deletion, username and display name are overwritten.
Stored Category
Entered by an authenticated user when creating an organization in the web interface.
Used to group events, admins, promos, bans, chat links, and queue settings under one organization.
Organization rows are deleted when an owner or system admin deletes the organization. They are not currently age-deleted automatically.
Stored Category
Created when an owner or system admin creates an admin invite and updated when the recipient logs in and binds the invite.
Used to grant, track, and revoke delegated access to an organization.
These rows are deleted when the organization is deleted. They are not currently removed by age-based retention.
Stored Category
Created from the web admin panel by an authorized user and updated later through event settings, headcount updates, and operational actions.
Used to run the queue, decide when joins and invites are allowed, calculate capacity, and drive on-site operations.
Automatically deleted after the event's retention window expires, or immediately if the parent organization is deleted. Before deletion, key free-text fields are overwritten with same-length replacement data.
Stored Category
Created when an admin posts an event message with /sendMessage or links a room with /orglink.
Used to know which Telegram rooms belong to which event or organization, to support chatty points, and to authorize room-scoped bot admin commands.
Automatically deleted when the association retention timestamp expires, or immediately if the parent organization is deleted.
Stored Category
Created when a user joins from Telegram or when staff perform a manual admit, and updated by bot invites, RSVPs, and door scans.
Used to run the queue state machine, issue and validate QR codes, track who is expected, and keep headcount estimates conservative.
Deleted when the parent event reaches its retention expiry or when the organization is deleted. Before deletion, manual labels and secret codes are overwritten.
Stored Category
Created or edited by authorized admins in the web interface.
Used to grant reusable bonus-point boosts during the Telegram join flow.
Automatically deleted when promo retention expires, or immediately when the parent organization is deleted. Before deletion, the code and success message are overwritten.
Stored Category
Created either by admin actions such as /award or automatically when a valid promo code is applied.
Used for weighted queue selection and for user point summaries in the admin interface.
Automatically deleted when the award retention timestamp expires, or immediately when the organization is deleted. Before deletion, the reason field is overwritten.
Stored Category
Built from Telegram activity in associated rooms only when chatty tracking is enabled. Message activity is first accumulated in memory and later written as weekly summary rows.
Used for weightedChatty queue selection and point summaries without storing a full permanent message log in the main database.
Automatically deleted when the summary retention timestamp expires, or immediately when the organization is deleted.
Stored Category
Created from moderation actions such as ban-by-scan or /sqban.
Used to block users from joining or remaining active in an organization's queue.
Ban rows are deleted when the organization is deleted. They are not currently removed by age-based retention. Notes are overwritten during organization deletion before the row is removed.
Stored Category
Written by the web admin client when it submits event actions such as scans, headcount changes, and invite confirmations.
Used to safely deduplicate retried actions when the connection is weak or a client resends the same request.
Automatically deleted when the parent event reaches retention expiry or when the organization is deleted. Before deletion, the idempotency key is overwritten and the stored response body is cleared.
Stored Category
Created when an admin uses event bulk commands in the web interface.
Used to queue bot-side mass actions such as messaging or cancelling groups of attendees and to track whether those jobs completed.
Automatically deleted when the parent event reaches retention expiry or when the organization is deleted. Before deletion, the action key, message text, and result message are overwritten.
Deletion Process