Reliability and Delivery Hardening
Not every update ships a new UI. Some of it is just making sure the pipeline doesn't quietly eat your data. This release is that kind of work: a set of infrastructure changes that make form submission processing durable, observable, and recoverable from end to end.
Durable ingest contract
The submission endpoint now returns an explicit 503 with a stable JSON error code when the database is unavailable, instead of swallowing the failure. Payload size limits are enforced at the gate, and canonical normalization is applied before anything is stored. Redirect URLs passed via _redirect are now strictly validated. If the value isn't a real URL, the submission still stores correctly but the redirect is ignored rather than bounced through unchecked.
Idempotency protection
Send an Idempotency-Key header with any submission and the endpoint will deduplicate within a configurable time window. Only the actual form data is considered for the match; metadata fields like _redirect, _test, and _honeypot are excluded. A database-level uniqueness constraint serves as the final backstop if two identical requests race past the application layer.
Async delivery with retry
Email delivery is now tracked in a dedicated delivery_attempts table. Failed deliveries no longer get dropped; they are retried with exponential backoff and jitter. If a delivery gets stuck and you don't want to wait, you can manually trigger a retry directly from the submission detail view.
Submission lifecycle log
Every submission now moves through four named states: received → stored → queued → sent (or failed). Each transition is timestamped. Failure reasons are sanitized before storage so diagnostic information survives without leaking sensitive context. Correlation IDs link the original ingest request to every downstream event, making it possible to trace a single submission across the full pipeline.
What you see in the dashboard
Status badges on the submissions list show delivery state at a glance, so there is no more guessing whether a notification went out. The submission detail drawer shows the last attempt timestamp, the failure reason if one exists, and a retry button when the delivery is in a recoverable state. Stuck or failed deliveries surface where you can act on them rather than being buried in logs.
This is plumbing, not a feature. But the pipeline is now observable and recoverable, which means everything built on top of it can be trusted a bit more.
We’d love to hear from you
Have feedback on this update, or an idea for a feature you’d like to see? We read every message and genuinely take them into account as we build.
hello@formtorch.com