Scheduled Actions
Create future moderation work, inspect queue state, cancel pending items, and review verified execution outcomes.
- Audience
- moderator · team lead
- Availability
- premium preview · private beta access
- Maturity
- alpha · partial
Last reviewed
On this page
What a scheduled action stores
Scheduled Actions store a supported moderation request for later processing. The dashboard exposes pending, executing, executed, failed, and cancelled states plus filtering and cancellation where the caller is authorized.
Check time, target, and live conditions
Open Scheduled Actions in the selected server dashboard to create supported future work, filter queue history, or cancel an eligible pending item.
- A supported action type, target, reason, and future execution time.
- Permission to create the action now and an expectation that live Discord conditions may differ later.
- A plan to review failed or uncertain outcomes.
Create, monitor, cancel, and verify
Create the schedule
Enter the target, supported action, reason, duration where applicable, and future time, then submit once.
Check: A pending item appears with its server, actor, target, and schedule.
Monitor queue state
Use filters to distinguish pending, executing, executed, failed, and cancelled records.
Check: Staff can see whether processing has started or reached a terminal result.
Cancel when eligible
Use the guarded cancel confirmation for a pending item that should no longer execute.
Check: The item becomes cancelled or explains why cancellation was no longer valid.
Verify execution
After the scheduled time, inspect the final state and linked moderation history before creating a replacement.
Check: A success or failure is auditable and staff avoid duplicate execution.
Scheduled-action examples
Each scheduled request has a visible lifecycle from pending through execution, failure, or cancellation, with enough context for authorized recovery.
- Schedule a supported temporary action for a future time and verify the pending row.
- Cancel a pending item after the underlying incident is resolved.
- Investigate a failed item through its record instead of assuming it ran.
Scheduled action fields and planning checks
| Field | Question to answer | Common risk |
|---|---|---|
| Action type | Which supported moderation action should run later? | Scheduling a different action than the reviewed decision. |
| Target | Is this the exact Discord user in the selected server? | Display-name confusion or target leaving before execution. |
| Execution time | What absolute server-relevant time should the action run? | Timezone, daylight-saving, or relative-time misunderstanding. |
| Duration | If the action is temporary, how long should it remain active after execution? | Confusing schedule time with action duration. |
| Reason | What policy context will the future executor/audit record need? | A vague reason that cannot be reviewed later. |
| Creator and permission | Who scheduled it, and are they authorized for this action? | Assuming current permission guarantees future target conditions. |
Queue states and operator response
| State | Meaning | Operator response |
|---|---|---|
| Pending | Eligible for future claim; has not started execution. | Review or cancel if the underlying decision changes. |
| Executing | A worker has claimed the item and is attempting the action. | Do not cancel or create a duplicate while the outcome is uncertain. |
| Executed | The supported action completed and a result was stored. | Open the linked moderation record and verify downstream state. |
| Failed | The attempt reached a recorded error or unmet live condition. | Read the error, verify Discord state, and decide whether a new authorized item is appropriate. |
| Cancelled | An eligible pending item was stopped before execution. | Confirm no linked action record exists and record why the schedule changed. |
Time, ownership, and shift handoff
Use an absolute reference
Record the date, local timezone, and displayed UTC/Discord timestamp where available.
Check: The next shift can interpret the intended time.
Assign monitoring ownership
Name who should verify the result after execution, especially for high-impact actions.
Check: A failed item does not remain unseen.
Check before shift end
Review items due during or soon after the handoff window and note pending/cancelled changes.
Check: The next shift inherits a clear queue state.
Check after execution
Compare the scheduled item, moderation record, and current Discord state.
Check: The team knows whether the intended effect actually occurred.
Scheduled-action recovery scenarios
Pending after the scheduled time
What you see: The item still appears pending after its intended execution time.
What may be happening: The page can be stale, the worker may not have claimed it, server access may be paused, or the timestamp may have been interpreted differently.
What to do
- Refresh and clear filters.
- Confirm the exact absolute execution time.
- Check System Health for user-visible worker/queue status.
- Do not create a replacement until the original is confirmed not executing.
Failed target or permission
What you see: The item failed because the target was absent, already in the intended state, above hierarchy, or no longer actionable.
What may be happening: Live Discord conditions are rechecked at execution time and can differ from creation time.
What to do
- Read the linked error and current target state.
- Decide whether the objective is already satisfied or no longer valid.
- Correct permissions only when policy authorizes it.
- Create a new item only with a fresh human decision.
A queue entry is not a guarantee
The current guide does not promise a Run now control. Execution depends on the scheduled job, current permissions, target state, and supported action handler; cancellation can race with processing once an item leaves pending state.
Recover a stuck or failed item
The result is not what you expected
What you see: A scheduled item is missing, stuck, failed, or cannot be cancelled.
What may be happening: Filters, stale state, invalid live conditions, permission changes, worker processing, or a transition out of pending can explain the result.
What to do
- Clear filters and refresh the queue.
- Read the current state and error before acting.
- Check moderation history for an execution record.
- Create a replacement only after confirming the original did not execute.
Handoff should include the scheduled item identifier, intended time, current state, and linked moderation record where one exists.
What happens when scheduled work is due
Scheduled moderation can queue supported actions such as unmute, unban, release from Jail, or another explicitly configured follow-up. A worker claims due work, checks current entitlement and authority, records attempts, and uses idempotency protections before applying a supported action.