Set up your space.

Invite & setup

Join Snoozer Bot Central for community and setup guidance. The invite is for the community server; running the bot itself requires an operator to set up and keep the process running.

1. Download or clone the bot project and open its folder.
2. Use Python 3.10 or newer. The bot uses the Python standard library and has no third-party package dependencies.
3. On Windows, run start_snoozer.bat; on other platforms, run python main.py.
4. On first launch, enter the private Yapper bot token and owner user ID when prompted. Token input is hidden.
5. Keep the process running for events, scheduled reminders, and temporary-role removals.

Keep the bot process on an operator-controlled machine and never publish its private configuration or runtime data.

Roles & permissions

In each server, the owner can set Snoozer's staff roles using /setmodrole and /setmanagerrole. Review that server's values and module state with /config. The configured owner, moderator, and manager roles govern Snoozer commands, while Yapper independently enforces the bot's platform permissions.

• Owner: the Yapper user ID entered during first-run setup; can configure Snoozer's moderator and manager roles.
• Moderator: role set with /setmodrole; can use moderation commands.
• Manager: role set with /setmanagerrole; can manage server settings and modules.
• Bot permissions: grant only the Yapper permissions Snoozer needs for the actions you enable.

Some commands need additional Yapper permissions, such as Manage Messages for /purge. A role inside Snoozer does not override the platform's permission checks.

Command overview

The command picker is shared at bot level and limited to 100 registered entries. Some secondary aliases may be prefix-only; try !command if a command is not in the slash picker. The overview below is not complete; follow each command's documented usage and access requirements.

Information & utilities

/help, /info, /ping, /stats, /uptime, /serverinfo

Community

/poll, /suggest, /giveaway, /remindme, /rank, /leaderboard, /balance, /daily, /pay, /afk

Moderation

/kick, /ban, /timeout, /warn, /note, /modlogs, /case, /purge, /lock

Server management

/setmodrole, /setmanagerrole, /setlogchannel, /setwelcome, /autorole, /automod, /module, /command, /config, /diagnose

These are an overview, not a complete list. Exact syntax, limits, aliases, and permission notes are set out in the bot project's command reference.

Separate server scopes

One Snoozer process can serve multiple Yapper servers. Moderation roles, modules, channels, welcome settings, custom commands, activity, economy, polls, giveaways, and reminders use server-specific scopes. Reminder listings and cancellation stay within the current server; giveaway entries and draws cannot operate on another server's giveaway.

Yapper registers one command menu for the bot, so custom command names configured in different servers are combined in that shared menu. A custom command responds only in servers where it is configured. Secondary and unlisted commands may require the documented prefix form.

The local JSON store is not a shared database for multiple processes. Do not run multiple Snoozer instances against the same JSON file; the project README says this requires replacing local JSON storage with a shared transactional database first.

Configuration & local data

The private bot token is entered at setup and saved in the operator's local config.json, which is ignored by Git. Runtime state is in data/state.json, also excluded from Git. Do not publish either file, and back up state securely. A manager can route moderation and available server-event logs to a chosen channel using /setlogchannel channel_id; these event logs include message contents.

Depending on enabled commands, local state can include server settings; user IDs; moderation records and private notes; reminders; poll and giveaway entries; activity XP, Snoozer Coins, and AFK state. The exact data present varies by usage and configuration.

The bot depends on Yapper for platform permissions, server actions, and API behavior. Availability and action outcomes can therefore also depend on Yapper and the operator's bot setup.

The Yapper bot event API does not deliver every kind of server change (for example, message edits/deletions or role/channel changes), so the event logger is not a complete audit trail. See the Privacy page for what event logs contain.

Status endpoint

The website does not include a status server or bot token. Its status page requests the public HTTPS endpoint configured in website/assets/js/config.js. This installation currently uses a Cloudflare Quick Tunnel:

That URL must serve JSON matching this contract. These are field definitions, not live readings:

status

String: exactly "online" or "offline", based on the endpoint's actual check.

version

String identifying the reported bot version.

server_count

Non-negative integer reported by the bot, or null when no count is available.

command_count

Non-negative integer count of parsed, enabled command events recorded by the bot.

message_sent_count

Non-negative integer count of successful bot message-creation API calls, persisted in the bot's state file. Message edits, deletions, and failed requests are not counted.

checked_at

ISO-8601 UTC timestamp ending in Z or +00:00.

uptime_seconds

Non-negative number of seconds reported by the process.

Serve the JSON through an HTTPS reverse proxy or a properly secured tunnel; do not expose the bot's raw unauthenticated HTTP listener or put any bot token in the page, response, or browser config. Expose only the intended read-only status data, configure cross-origin access for the published site, and test the endpoint without secrets. Anyone able to load the public website can see the status fields it returns. For dependable long-term hosting, use a named Cloudflare Tunnel with a domain you control instead of a Quick Tunnel.

If the URL is unset, HTTPS is unavailable, CORS blocks the browser, the endpoint cannot be reached, or the JSON is invalid, the page shows “Unable to verify.” An endpoint failure is not presented as proof that the bot is offline.

Troubleshooting

• A command is missing from the picker: the shared menu is limited to 100 entries; try the documented prefix form for commands that are not in the slash picker.
• An action is denied or fails: check the server's configured staff roles with /config and confirm Yapper granted the bot the permission for that action.
• Settings seem different between servers: configuration is intentionally server-specific; use /config in the server being checked.
• Scheduled tasks are late or missing: the bot process needs to remain running for reminders and temporary-role removals.
• Status says it cannot verify: confirm the configured HTTPS endpoint, response contract, reachability, and browser CORS access. This state does not mean the bot is offline.

For community support, use the Help page and the Snoozer Bot Central server.