Submissions & jobs

A submission is what arrived from your website — one person filling in one form, once. A job is one delivery attempt to one recipient. They are separate records, and keeping them separate is the point.

If a form has three recipients, one submission produces three jobs. Those three jobs succeed or fail independently: two can be delivered while the third bounces. So “the form is broken” and “one recipient did not get the email” are different problems, and they live on different pages.

Submissions

Submissions lists everything your forms received, newest first. Nothing on this page can fail — if a row is here, the data was captured and stored.

Filter with All sites, then All forms (which unlocks once a site is chosen), a Date Range, and a Search box that matches on the submitted content. The table shows the submission ID, Site, Form, Source, and Date. Source is browser for a real form post and api for anything sent directly by a developer.

Click any row to open the detail panel. It shows the site, form, source, originating IP, timestamp, and then every field value the visitor actually submitted — the name, email, message, and any custom fields your form collects.

Export CSV, at the top right, downloads the currently filtered submissions as a spreadsheet. Site, form, and date filters carry into the export; the search text does not. The export is capped at 10,000 rows, and you get no warning when it truncates — narrow the date range if you are exporting a busy period.

Screenshot to come

The Submissions list with the site, form, date range, and search filters above a table of submitted rows

What Expeed Relay refuses to accept

A few submissions never become rows on this page, because Expeed Relay rejects them at the door. When someone reports that a form “silently did nothing”, these are the usual explanations — and none of them leave a trace in Submissions, precisely because no submission was created.

Too many submissions from one visitor. Public form submissions are rate limited to ten per minute per IP address. That figure is fixed — it is not something you or your administrator can raise from the dashboard. A real person filling in a contact form will never come close. Someone testing a form repeatedly will hit it easily, and because the limit counts by IP, everyone behind the same office or VPN connection shares one allowance. It clears by itself after a minute.

A payload that is too large. One submission may carry at most 100 fields, and no single field value may exceed 10,000 characters. Field names are capped at 128 characters and the whole request body has a size ceiling of its own. Over-limit requests come back with a message naming the specific limit that was hit, so ask the developer to quote the error verbatim.

A field using a reserved name. The names _subject, _body, and _footer are reserved — they control the outgoing message, so a public form is not allowed to set them. A form collecting a field with one of those names is rejected until it is renamed.

A rejected submission is not the same as a failed delivery. Everything above happens before a submission exists, so there is nothing on Submissions and nothing on Jobs to look at. If a form is producing no rows at all, the cause is here or in CAPTCHA setup — not in your providers or recipients.

Jobs

Notification Jobs is the delivery log. Filter by All sites and All. Columns are ID, Channel, Recipient, Status, Attempts, and Date, plus an Actions column if you are an admin or manager.

Screenshot to come

The Notification Jobs list showing the status column with a mix of delivered, failed, and dead jobs

There are five statuses:

• pending — queued, not picked up yet. Normal. No action needed.
• processing — a delivery attempt is running right now.
• delivered — the provider accepted the message. This is the finish line.
• failed — an attempt failed, but Expeed Relay will try again automatically. Attempts are spaced out on a growing delay, starting around a minute apart.
• dead — every attempt was used up (five by default, though your administrator can change it). Expeed Relay has stopped trying. This one needs you.

Watch the Attempts column: a job climbing toward the limit is heading for dead.

A job stuck in processing now recovers on its own. It means the worker started the attempt and never finished — usually a restart mid-send, or a provider connection that hung. Expeed Relay sweeps for these and reclaims any job whose worker has gone quiet for too long, counting it as a failed attempt and queueing it again, or marking it dead if its attempts are spent. You do not need to do anything; wait a few minutes and it will move on by itself. If jobs are repeatedly getting stuck, that is worth raising with your administrator — it points at the worker, not at your configuration.

Retrying a job

1. Open Jobs from the sidebar and set All to Failed or Dead.
2. Find the job. The Retry button only appears on failed and dead rows — there is nothing to retry on the others.
3. Fix the underlying cause first. A retry re-runs the exact same delivery, so retrying before the fix just burns another attempt.
4. Click Retry and confirm in the Retry this delivery? dialog.
5. The job resets to pending with its attempt count back to zero, and the delivery starts over from a clean slate.

Retry is limited to Admin and Manager roles. Viewers see the jobs list without an Actions column. Managers can only retry jobs belonging to sites they have been granted access to. See Users & roles.

When jobs fail

• Wrong or expired provider credentials — every job for that site and channel fails together, which is the giveaway. Open the site’s Providers tab, re-enter the credentials, then retry. See Configuring providers.
• No active provider for the channel — same symptom, but the site never had one configured, or it was switched off. Add or re-activate the provider.
• Invalid recipient address — a single recipient fails while the others on the same submission are delivered. Correct the address on the form’s Recipients tab, then retry. See Forms & recipients.
• Upstream rate limiting — a burst of failures during a traffic spike, clearing on its own. The automatic attempts usually recover these. Wait, then retry anything left as dead.

Related

• Configuring providers — fix the credentials behind most delivery failures.
• Forms & recipients — change who receives a form’s notifications.