How alerts get routed without spamming anyone

A store might want customers emailed the moment their card is about to expire, but not want them emailed every time a grace period ticks up a day. Those are legitimate, different preferences — so the plugin doesn't treat "send an email" as one setting.

Four independent switches

Grace warning, grace critical, expiring card and failed payment each get their own on/off toggle and their own recipient mode — admin, customer, or both. Turning on customer emails for expiring cards says nothing about whether customers also get grace-period warnings; that's a separate decision, made separately.

Two templates for every risk

The admin copy and the customer copy of an alert are configured as separate templates — different subject lines, different bodies, because an admin and a customer need different information from the same event. Each also carries a configurable action link, pointing either to manage the subscription or to update the payment method directly.

The cooldown that keeps it from feeling like spam

A subscription that's been sitting in Critical for three weeks doesn't get a fresh email every single day the scan runs. A 35-day cooldown applies per subscription, per email type — so the same alert won't fire again for that subscription until the cooldown clears, even if the underlying risk is still there scan after scan.

Everything sent gets logged

Every attempted send — successful, failed, or skipped by the cooldown — is written to the plugin's own email audit log, along with the recipient, the email type and a timestamp. Nothing about what went out, or why something didn't, is a mystery later.