Getting started

Raid Ping reminds the raiders who still have not answered a Raid-Helper signup. It is not an addon: a small Python script runs in a GitHub Actions workflow once an hour, reads the signup through Raid-Helper's API, and posts a reminder to Discord naming who is missing — inside the window you set, and never twice for the same event.

What it needs#

• A Discord server where the Raid-Helper bot posts signup events, one signup channel per team.
• A Raid-Helper API key for that server: type /apikey to the bot, in the server itself.
• A private GitHub repository with Actions enabled. The config holds Discord ids, which is why it stays private.
• One Discord incoming webhook per channel the reminders should post to, stored as a repository secret.
• An external hourly scheduler that can POST with custom headers (the live setup uses cron-job.org), holding a fine-grained GitHub token scoped to this repository with Actions read and write.
• Discord user ids for every raider on the roster, copied as text with Developer Mode on.

Nothing to pip-install: the script is standard-library Python 3.10+, which GitHub's runners have.

In order#

1. Repository, config and secrets — create the private repository, add the project files, fill config.json (server id, the rosters table, one teams entry per signup channel), and add the secrets. Set up the repository, config, and secrets is the checklist.
2. A dry run by hand. In the GitHub web UI: Actions → Raid-Helper signup nag → Run workflow. Both inputs default to true (dry_run, ignore_window), so the plain button reads the signup and prints who would be pinged without posting anything.
3. The hourly trigger. Point the scheduler at the workflow's dispatch endpoint with dry_run false, and it is live. Wire the hourly trigger and go live.

Week to week#

• Roster changes and message wording are edits to config.json; Edit the roster or message templates safely says how to change them without a bad run.
• A second team is a second teams entry and a second webhook.
• When a run misbehaves, the workflow log says which step, and Read the run log and fix the common failures covers the usual three.

The one date to remember#

The scheduler's GitHub token expires. Note the date in the repository when you create it — the runbook keeps the current one — because the first sign of an expired token is silence before a raid.