Which dedupe strategy fits Deta Space scheduled actions for low-noise alerts?

I'm building a Deta Space app that runs a scheduled action (cron trigger declared in the Spacefile) to check a condition — for example, stale data or a quota threshold — and send a notification through a third-party channel like a Slack webhook or email. Since Space has no built-in alerting or notification subsystem, all of this logic lives in my own code.

The part I haven't resolved is how to suppress repeat notifications cleanly. My plan is to store a small record in Deta Base (a 'last alerted at' timestamp or a dedupe key) so the scheduled run only notifies when the condition newly appears or has persisted past a cooldown window. But I'm unsure how to structure that record so it behaves correctly when the condition flaps — clearing and re-triggering around the threshold — and whether per-installation state is enough given that each user installs their own copy of the app.

I'm assuming a current Spacefile cron setup and the Base SDK, though I still need to confirm both are unchanged in Deta's current platform state.

Should the dedupe state live in Deta Base or Drive, and what key structure handles flapping conditions best? What cooldown or threshold pattern avoids both missed alerts and duplicate noise? Are there documented limits on scheduled action frequency that constrain how fine-grained the checks can be?