Gravity Forms can have a documented spam retention period while WP-Cron is disabled, starved by low traffic, blocked by a failed worker, shifted by timezone changes, or intentionally bypassed for a legal hold. Teams need an observable comparison between policy, eligible records, scheduled events, actual deletions, and exceptions.
Use this for sites with spam entries, server cron, WP-Cron replacements, low traffic, background queues, backups, legal holds, privacy commitments, or external form exports.
Quick answer
For each form, calculate the oldest entry eligible under the current policy, inspect the scheduled cleanup event and its last successful run, and count eligible, held, and deleted rows. Alert when eligible records remain beyond a defined grace window or when the event has not run on schedule.
What to check first
- Record per-form retention days, timezone, spam count, oldest spam timestamp, legal holds, backup retention, external copies, cron mechanism, event name, and expected cadence.
- List due cron events and correlate the last start, completion, duration, worker, deleted count, held count, error, and next schedule.
- Simulate disabled WP-Cron, low traffic, overlapping workers, PHP fatal, database timeout, timezone change, and a legal-hold exclusion on staging.
- Compare eligible rows before and after the run, including entry meta, uploaded files, add-on data, logs, backups, and remote destinations covered by policy.
- Set alert thresholds for missed runs, oldest eligible age, growing backlog, partial deletion, repeated failure, and a schedule that silently disappears.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
| Document policy and data locations | Record per-form retention days, timezone, spam count, oldest spam timestamp, legal holds, backup retention, external copies, cron mechanism, event name, and expected cadence. | Oldest eligible age stays within the policy plus grace window. |
| Measure cron schedule and actual runs | List due cron events and correlate the last start, completion, duration, worker, deleted count, held count, error, and next schedule. | Every run records start, completion, counts, and errors. |
| Inject scheduler and worker failures | Simulate disabled WP-Cron, low traffic, overlapping workers, PHP fatal, database timeout, timezone change, and a legal-hold exclusion on staging. | Legal holds are excluded and attributable. |
| Reconcile eligible, held, and deleted records | Compare eligible rows before and after the run, including entry meta, uploaded files, add-on data, logs, backups, and remote destinations covered by policy. | A missed or failed run produces an actionable alert. |
Why this usually happens
- WP-Cron depends on requests unless a real scheduler invokes it.
- A fatal error can leave the next event scheduled while no cleanup completed.
- Timezone or policy changes can move the eligibility boundary.
- Legal holds and backups can retain data outside the primary entries table.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
form_id: 18
retention_days: 30
timezone: America/Chicago
oldest_eligible: 2026-06-12T14:22:00Z
eligible_rows: 184
legal_hold_rows: 3
last_successful_cron: 2026-07-23T05:05:11Z
missed_runs: 2
alert_threshold_hours: 30
status: alert
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Document policy and data locations
- Measure cron schedule and actual runs
- Inject scheduler and worker failures
- Reconcile eligible, held, and deleted records
- Alert on age, backlog, and missing events
Decision rule
Pass when the scheduler runs at the documented cadence, eligible data is deleted or explicitly held, files and add-on locations follow policy, failures alert within the threshold, and the next run remains scheduled.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- Oldest eligible age stays within the policy plus grace window.
- Every run records start, completion, counts, and errors.
- Legal holds are excluded and attributable.
- A missed or failed run produces an actionable alert.
Mistakes to avoid
- Do not change several plugins, cache rules, or infrastructure settings before preserving a baseline.
- Do not treat one successful test as proof for retries, alternate clients, or delayed background work.
- Do not paste secrets, personal data, or complete production payloads into tickets or screenshots.
- Do not close the test until the final user-visible state and server-side evidence agree.
Questions teams ask during testing
Can the retention setting alone satisfy a deletion policy?
No. It expresses intent. Monitor actual eligible rows, cron completion, files, backups, and external copies.
Should a monitor trigger the cleanup job automatically?
It can, but prevent overlapping workers and preserve failure evidence. Alerting and controlled retry are safer than repeated blind execution.
When HandL WP should help
Bring in HandL WP when this affects a production site, paid lead flow, checkout, email delivery, or a managed fleet. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, the external service, logs, and the user journey.
If this is active on a production site, monitor Gravity Forms retention jobs.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Verify uploaded files leave with expired spam
A deleted entry does not prove every copy is gone. Use the Gravity Forms spam retention file deletion coverage test to reconcile local uploads, object storage, CDN, add-ons, notifications, logs, and backup expiry.
Helpful references