SheetLink Forms beta

Delivery log

Definition

A delivery log is a per-submission record of what happened after the data arrived: when delivery was attempted, to which destination, whether it succeeded, and when the next attempt is due if it failed. It is the audit trail that turns "did my form data make it?" from a feeling into a lookup.

The need comes from asynchronous delivery. Any robust pipeline acknowledges the submission first and delivers it afterward, in a background worker, with retries - which means the visitor-facing "success" only ever meant "received", not "delivered". Something must account for the second half of the journey, or failures are invisible precisely when they matter most: an expired credential or an API outage can quietly stall deliveries for hours while everything looks fine from outside.

A good log therefore shows state per submission (delivered, retrying, failed), timestamps per attempt, and enough error context to act on - reconnect the account, fix the destination, retry by hand. Paired with a bounded retry schedule, it completes a simple contract: the system keeps trying without your attention, and when your attention is needed, the log says exactly where and why.

How SheetLink Forms uses it

SheetLink Forms keeps this contract in the dashboard. Every submission is stored on arrival, then an asynchronous worker writes the row directly to the Google Sheets API or Microsoft Graph; failures retry at 5 minutes, 30 minutes, and 2 hours, and every attempt is visible in the delivery log with its state. Because the submission is stored before delivery is tried, a failed write is a delay, not a loss.

The pipeline the log observes is drawn out on how it works, with worker and retry behavior detailed in the docs.

Related terms: Retry with backoff · Form backend · OAuth refresh token