Inspiration
Every Reddit moderator knows the frustration: a user gets their post removed, comes back a week later, breaks the rules again, and the mod team has no idea this is the third time it's happened. AutoModerator is powerful, but it has no memory. It can remove a single post — but it can't say "this user has been removed 5 times this month."
I built RecidivWatch to solve exactly that problem. Mods shouldn't have to manually dig through user histories every time someone reoffends. The pattern should be tracked automatically, and the mod team should be alerted before the situation escalates.
What it does
RecidivWatch runs silently in the background of any subreddit it's installed on. Every time a moderator removes a post or comment, the app records it against that user's profile. When a user hits configurable thresholds, the mod team receives an instant modmail alert with the full violation history, timestamps, content previews, and a direct ban link.
Three alert levels:
- ⚠️ Warning — 3 removals in 7 days
- 🚫 Temp Ban Recommendation — 5 removals in 7 days
- ⛔ Perm Ban Recommendation — after 3 temp ban alerts triggered
Smart logic prevents alert spam — a 24-hour cooldown between alerts, escalation memory so warnings don't repeat, and deduplication so the same removal can never be counted twice.
Mods can also right-click any post or comment to instantly view a user's full violation history or reset their record if they've reformed.
How I built it
RecidivWatch is built entirely on Devvit — Reddit's native developer platform. No external APIs, no third-party databases, no webhooks.
- ModAction trigger listens for every
removelinkandremovecommentevent in real time - Redis (Devvit KV Store) stores per-user violation records persistently
- Modmail API sends formatted alerts directly to the subreddit's mod team
- Context menu items give mods right-click access to user history and record resets
- All settings (thresholds, lookback window, cooldown, trusted flairs) are configurable per subreddit through Devvit's native settings system
The app is structured in a clean separation of concerns — settings.ts for types
and config, tracker.ts for all Redis logic and alert evaluation, alert.ts for
modmail building and sending, triggers.ts for event handling, and menu.ts for
context menu items.
Challenges I faced
Getting the right event type was the first major hurdle. PostDelete and
CommentDelete events don't expose which moderator took the action — only
ModAction does. Switching to ModAction with removelink and removecomment
filters gave us full mod attribution.
Duplicate event firing was a real issue early on — the same removal was being recorded multiple times because multiple events fired for a single action. Fixed with content ID deduplication in the Redis record.
Type errors from incorrect Devvit API assumptions took time to resolve —
fields like event.targetUser return a UserV2 object, not a plain string, and
TriggerContext is a subset of the full Context type that doesn't include ui.
Reading the actual type definitions carefully fixed these.
Alert cooldown design required thinking through edge cases — what happens when a user is right on the boundary of two thresholds, or when the same content fires multiple events? The final design uses per-level cooldown timestamps and escalation flags stored in the user record.
What I learned
- How Devvit's event system works and which events expose what data
- How to design a stateful Redis-backed tracking system within Devvit's KV store
- The importance of deduplication in event-driven systems
- How to structure a multi-file Devvit app cleanly for maintainability
What's next
- Weekly digest — a scheduled Sunday modmail listing all users currently above the warning threshold
- Cross-subreddit mode — for mod networks running multiple communities
- User notes — let mods attach a text note to a user's record via the right-click menu
Log in or sign up for Devpost to join the conversation.