Backup Verification
Prove your backups restore, instead of trusting that they exist.
What it adds
Automated checks that a backup is complete, encrypted, retained, and actually restorable — with a recorded test restore rather than an assumption.
What your agent is told to do
6
What your agent is told to do
6-
1
Inventory what must be backed up first: every database, every uploaded-file store, and any external state the app cannot rebuild. A backup covering only the primary database is a partial backup, and should be reported as one.
-
2
After every backup, verify it mechanically: the file exists, its checksum matches, its size is within a sane band of the previous run, it is encrypted, and it is where the retention policy expects it.
-
3
Restore on a schedule into a fully isolated environment and assert against the restored data — row counts within expected ranges, the newest record close to the backup time, and a handful of known invariants.
-
4
Neutralise all outbound side effects in the restore environment before the data loads. Disable mail, webhooks, payment calls, push notifications, and analytics at the configuration level, not by hoping the code paths are not reached.
-
5
Record recovery-point and recovery-time evidence for each test: how much data would have been lost, and how long the restore took. Trend both over time — a restore that gets slower each month is a future incident.
-
6
Do NOT treat a successful backup job as a successful backup. A zero-byte file uploaded without error passes every check that only looks at the exit code.
Edge cases it handles
7
Edge cases it handles
7- The restore environment must never be able to reach production credentials, queues, or third-party accounts. Verify the isolation as part of the test, not once at setup.
- Restored data is production data. It carries the same access controls, retention obligations, and deletion requests, and the environment must be destroyed after the test.
- A size band catches truncation but also fires on legitimate growth. Compare against a rolling baseline rather than a fixed number.
- Verify that the encryption key needed to restore is itself recoverable and stored separately from the backup. A backup you cannot decrypt is not a backup.
- Retention deletion must be checked in both directions: old backups actually removed, and recent backups not removed early.
- A failing verification must alert loudly. Silent verification failures produce a system that has looked healthy for months.
- Uploaded files and database rows can drift apart. Check that a sample of restored records still points at objects present in the restored file store.
Definition of done
9
Definition of done
9- Every data store requiring backup is inventoried, and partial coverage is reported as partial.
- Each backup is checked for existence, checksum, size band, encryption, and retention placement.
- A scheduled test restore runs into an isolated environment and asserts data invariants.
- Mail, webhooks, payments, and push are disabled by configuration in the restore environment.
- Recovery-point and recovery-time figures are recorded per test and trended.
- Restore environments are destroyed after verification.
- A failed verification raises an alert rather than being logged quietly.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Upload Malware Scanning
Upload Malware Scanning
Quarantine uploaded files until they are known safe.
What it does
A quarantine lifecycle for uploads: every new file is unreachable until scanned, with defined handling for scanner failures and infected results.
How it works
- 1 Give every upload an explicit scan state — pending, clean, infected, or error — and default it to pending the moment the bytes land.
- 2 Make pending and infected files unreachable from every access path in the app, including admin views, previews, thumbnails, and any signed URL. A quarantine with one exception is not a quarantine.
- 3 Scan asynchronously and update the state; do not block the upload request on the scanner.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/upload-malware-scanning
Rate Limiting
Rate Limiting
Stop one client from ruining it for everyone.
What it does
Throttling on the endpoints that get abused: auth, search, exports, and public forms.
How it works
- 1 Identify the endpoints worth protecting: sign-in, sign-up, password reset, search, exports, and anything unauthenticated.
- 2 Limit by a stable identifier — user ID where signed in, IP otherwise. Be aware IP is shared behind NAT and proxies.
- 3 Return 429 with a Retry-After header. Do not silently drop the request.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/rate-limiting
Password Generator
Password Generator
Offer a strong password in one click wherever someone sets or changes credentials.
What it does
A generate control on password fields that produces a strong value, shows it, and hands it to the user safely.
How it works
- 1 Add the control to every place a password is set: sign-up, password change, password reset completion, and any admin screen that provisions credentials for someone else.
- 2 Generate the value in the browser using the platform's cryptographic random source. The value must never be produced on the server or sent anywhere.
- 3 Reveal the generated password by default so the user can record it, and offer a regenerate control beside it. A hidden generated password that the user cannot see is a password they will immediately reset.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/password-generator
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.