---
title: "Before You Begin: Requirements and Cron"
description: "Five minutes of setup here prevents the most common support question: *\"why didn't it run?\"* --- ## Requirements | Requirement | Notes | | --- | --- | | **Gravity Forms** | Required. The plugin is a Gravity Forms add-on…"
url: "https://brightleafdigital.io/docs/before-you-begin-requirements-and-cron/"
updated: "2026-10-18"
category: Recurring Form Submissions for Gravity Forms / Getting Started
---

# Before You Begin: Requirements and Cron

Five minutes of setup here prevents the most common support question: *"why didn't it run?"*

---

## Requirements

| Requirement | Notes |
| --- | --- |
| **Gravity Forms** | Required. The plugin is a Gravity Forms add-on and shows an admin notice if Gravity Forms is missing or inactive. |
| **PHP 8.0 or newer** | Enforced by the plugin. |
| **A working WordPress cron** | Essential. See below — this is the one that bites. |
| **A named site timezone** | Strongly recommended so schedules follow daylight-saving changes. |
| **GP Populate Anything** | Optional. Only needed if you want lookups re-evaluated on every run. |

---

## The Cron Requirement (Read This One)

The plugin asks WordPress to run a background check **every 15 minutes**. Scheduling that request is easy; actually running it depends on your host.

**Three things have to be true:**

1. WordPress is invoked frequently enough — by visitors, or by a server-side cron.
2. Its cron system is not disabled.
3. The check completes and records a heartbeat.

### Why "my cron works" isn't enough

A daily server cron cannot satisfy a 15-minute interval. Neither does "our other scheduled task runs fine" — that task might be daily too.

The plugin therefore reports **three separate numbers** in Queue and Settings:

| Reading | Meaning |
| --- | --- |
| **Requested interval** | How often the plugin wants to run (900 seconds by default). |
| **Registered interval** | What WordPress actually has on its schedule. |
| **Last heartbeat** | When PHP last *finished* a check. This is the only real proof. |

A heartbeat older than **twice** the requested interval is flagged as late. A brand-new installation gets a two-interval grace period.

### Recommended host setup

Ask your host (or your systems team) to invoke WordPress cron **every 5 to 15 minutes**:

```
*/10 * * * * cd /path/to/site && php wp-cron.php > /dev/null 2>&1
```

Running that every minute is harmless — it simply executes whatever events are due, and this plugin's event is only due every 15 minutes.

> **Careful:** opening `wp-cron.php` in a browser and getting an HTTP 200 proves WordPress responded. It does **not** prove this plugin's worker ran, because the worker only runs when its own event is due.

---

## Set Your Timezone Properly

Go to **Settings → General → Timezone** in WordPress.

- **Choose a city** (for example `New York`, which stores `America/New_York`).
- **Avoid a raw UTC offset** such as `UTC-5`.

A named timezone follows daylight saving automatically, so an 11:00 schedule stays at 11:00 all year. A fixed offset cannot do that — an 11:00 schedule silently becomes 10:00 or 12:00 for half the year.

The feed editor links straight to this setting when it notices the site is using an offset.

---

## Decide Who Can Manage Schedules

Every operational button — run, retry, pause, resume, cancel, change date — requires the capability:

```
recurring_form_submissions_manage_resubmissions
```

Administrators receive it automatically. To let an editor or a custom role operate schedules, grant that capability with your role editor of choice.

It also governs the shortcodes: a user without it sees **nothing at all** from `[rfsfgf_overview]` or `[rfsfgf_entry_widget]`, not merely a version without buttons.

---

## Expectations Worth Setting Up Front

- **Submissions run a little late, by design.** A healthy worker starts an occurrence between its target and roughly 15 minutes afterwards. If you need second-level precision, this is not the right tool.
- **A schedule is a snapshot.** Editing a feed does not move schedules that are already running.
- **The first occurrence is a full interval away.** A daily feed saved at 01:14 with a run time of 01:20 starts *tomorrow* at 01:20 — not six minutes from now.
- **Nothing is backfilled.** Downtime never produces a burst of submissions.

---

## A Five-Point Pre-Flight Check

Before you rely on a schedule in production:

1. Site timezone is a named city, not an offset.
2. Server cron invokes WordPress at least every 15 minutes.
3. **GravityOps → Recurring Submissions → Settings** shows a healthy worker with a recent heartbeat.
4. An Admin Email is set, so failures reach a person.
5. You have run one series end-to-end with **Run Next Submission Now** and inspected the child entry it created.