A Gravity Forms entry limit counts eligible submitted entries, not simply successful payments. Your form can reach its limit while the paid-booking count is lower. Check the counting rules before deleting entries or increasing capacity.
The Gravity Forms entry-limit reference says fully submitted entries generally count, including failed, pending, processing, and refunded payment states. Spam, trash, and partial entries are excluded. Time-based resets use the WordPress site timezone.
Confirm which restriction closed the form
Open the exact form's settings and inspect Restrictions. Record the entry limit, selected period, limit message, and any scheduled start or end time. A scheduled expiration and a quota failure may both make a form unavailable, but changing one will not fix the other.
Also confirm the embedded form ID. A duplicated event page may still point to last month's form. Check the published page as a signed-out visitor rather than relying on an admin preview.
Build a count ledger
Use a small, authorized export or the Entries screen to list IDs and relevant statuses for the active period. Keep personal answers out of the working sheet. Separate the entry status from the payment status; they answer different questions.
For an illustrative cap of ten submissions, seven paid entries, two pending payments, and one failed payment can already account for ten eligible entries. That does not mean ten paid seats. Adding three spam records does not automatically increase this example's eligible count.
Scope: Correct form and period. Status: Entry versus payment separated. Boundary: Cap-reaching attempt tested. Capacity: Do not assume paid-seat inventory. Explanatory checklist, not a customer test result.
Write down which rows you believe count and why. Then compare the ledger with the form's limit behavior. If the count still differs, inspect custom filters and add-ons that change entry-limit behavior before editing historical records.
Check the boundary, not just today's total
Record the WordPress timezone and the entry timestamps as interpreted by the same reporting view. A daily reset is not necessarily midnight on the laptop used to inspect the form. Do not change the entire site's timezone to reopen one registration form; scheduled posts and other jobs may depend on it.
On staging, use a low test cap and synthetic entries. Verify the submission immediately before the cap, the cap-reaching submission, and the blocked attempt afterward. Test the next reset boundary appropriate to the configured period. Confirm the message offers an honest next step, such as contacting the organizer or joining a separate waitlist.
Do not use deletion as a capacity strategy
Moving a failed payment to trash solely to free space can damage reconciliation and retention records. Decide whether the business needs a submission cap, a paid-booking inventory, or reserved capacity during payment. Those are different requirements and may need a purpose-built booking workflow.
An entry cap alone should not be assumed to guarantee transactional seat inventory under concurrent submissions. Test that requirement separately if overselling would be costly.
If entries exist but emails are missing, use the notification eligibility and delivery guide instead. HandL WP can reconcile the form's quota behavior from the form ID, period, redacted count ledger, and a repeatable boundary test.
References reviewed October 9, 2026. Examples are explanatory, not customer test results.