Render History

The History page shows every render job your account has submitted — from Studio sends, API calls, Zapier automations, and manual exports — along with live status, duration, and webhook delivery. Use it to track batches as they process, spot failures, and jump straight to your billing page.

Opening History

Click History in the top navigation bar. The page has three tabs: Renders (the job list covered below), Deliveries (every send to your organization webhook), and Edit Times (active editing time per design — useful for studio managers). Each tab is covered in its own section below.

The KPI summary row

Four summary cards appear at the top of the Renders tab:

• Today — number of renders submitted today.
• This month — running total for the current calendar month.
• In progress — renders that are currently queued or processing. The count turns amber when jobs are waiting.
• Failed (month) — renders that failed this month. The count turns red if any failures exist — a quick signal that something needs attention.

Filtering the job list

Use the two dropdowns above the table to narrow the list:

• Status — filter to All statuses, Queued, Processing, Complete, Failed, or Webhook failed. The last one is a shortcut: it shows jobs that rendered fine but whose webhook never landed.
• Time range — filter to All time, Today, Last 7 days, or Last 30 days.

When either filter is active, a Clear filters button appears to reset both at once. Changing a filter resets pagination to page 1.

Reading the job table

Each row is one render job. The columns are:

Why a webhook failed, and retrying it

When a job's webhook fails, a short line appears under the badge in the Webhook column telling you what the receiver did:

• unreachable — nothing answered at all, usually a network problem or a timeout.
• responded 503 (or whichever status came back) — the receiver answered, but not with a success.

Either line is followed by · attempt 3, the number of tries that have been made so far.

What you can do next depends on the kind of failure:

• If another attempt could still land — nothing answered, the request timed out, or the receiver said it was busy or broken — a Retry button appears on the row. Click it to send that one job's webhook again.
• If the receiver rejected the request outright, it will reject the same request again, so there is no button. The row reads Fix the endpoint to retry instead. Fix the receiving end, then re-send.

Retrying a whole page at once

A receiver that goes down takes out every delivery in a shoot at the same time, so you don't have to click row by row. When the current page has retryable rows, a Retry N failed webhooks button appears in the filter bar. It re-sends every recoverable job on the page in one action, up to 50 per click.

Each job is retried on its own, so one that fails again does not stop the others. When the batch finishes you get a summary of how many were delivered, how many are still failing, and how many were skipped (not attempted this time — run it again). "Delivered" means the receiver actually accepted the send, not just that a request was made.

To work through failures in bulk, set the Status filter to Webhook failed first — that narrows the page to exactly the rows the button acts on.

Pagination

The table loads 50 jobs per page by default (the API supports up to 200 per page for programmatic access). Use the Previous and Next buttons at the bottom to page through results. The count above the table — for example, 1–50 of 342 — updates as you navigate.

Refreshing while a batch drains

The page does not auto-refresh. While a batch of renders is in progress, click Refresh (top right of the page) to pull the latest job statuses and update the KPI cards. The In progress card is the easiest way to confirm when a batch has fully drained.

Where API and Zapier renders appear

History covers your entire account — not just Studio sends. Renders submitted via the API, a Zapier automation, or any other integration appear in the same table alongside Studio exports. If the render was tied to a Studio design, the design name and folder are shown; otherwise the template name appears instead.

Billing link

The Billing button at the top right of the History page takes you directly to your billing page, where you can see your current balance, recent charges, and auto-refill settings. Renders that appear as Complete here are the ones that count against your balance.

Deliveries tab

The Deliveries tab is the log for your organization webhook — the destination that Studio's Send To, Send-To presets, and a flow's Send To step all fire at. Those sends don't belong to a render job, so they never appear in the Renders tab. If a design was sent and never arrived at your receiving system, this is the tab to check.

[Screenshot coming: The Deliveries tab of the History page showing failed sends to the organization webhook, with the Result column and per-row Retry buttons]

The two tabs answer different questions. Renders tells you whether the callback attached to one render job was delivered. Deliveries tells you whether a design reached your organization webhook, however it was sent.

Reading the delivery table

The Result cell can carry up to three extra lines under the badge:

• after 3 attempts — shown when the send was tried more than once before it settled.
• The receiver's own reply, in red, which is usually the most useful clue about what it objected to. Hover it to read the whole message if it's long.
• A Retry button, or an explanation of why there isn't one.

Retrying a failed send

Retries work the same way as on the Renders tab. A send that could still land — nothing answered, the request timed out, or the receiver reported it was busy or broken — gets a per-row Retry button, and a Retry N failed sends button appears above the table to re-send every recoverable row on the page at once (up to 50 per click).

A send the receiver rejected outright can't be replayed from here. Its row reads Fix the endpoint, then send the design again — repair the receiving system, then re-send the design from Studio.

Once a retry has finally landed, the original failed row stays in the log for the record but its Retry button is replaced by A retry landed and the time it succeeded, so you can tell settled failures from open ones at a glance.

Filtering and paging

• The outcome dropdown offers Failed only — the default, because the log is there to surface problems — and All deliveries, which adds successful sends.
• Refresh re-reads the list; the tab does not poll on its own.
• The list pages 50 deliveries at a time, newest first, with Previous and Next at the bottom.

Arriving from a design's "Send failed" badge

When a design's last send didn't land, a red Send failed badge appears on its card in Studio. Click it and you land on this tab already filtered to that one design, showing every send attempt for it — successes included, so you can see whether a later attempt fixed it. A Showing one design — show all button at the top clears the filter and returns you to the full log.

Edit Times tab

The Edit Times tab shows how long each design was actively edited — measured in 30-second windows of real activity — from creation (or first human edit, for API-created designs) through the first send or editor close. It is visible to all org members, not just admins.

Two sub-tables appear:

• By editor — median and average active time per team member, with a count of designs and a separate outlier count (designs that exceeded the selected time cap).
• By design — one row per design, sortable by time spent, design name, editor, or end date. Designs created before activity tracking was introduced show a wall-clock estimate labelled est.

Use the time range selector (Last 7 / 30 / 90 / 365 days) and the outlier cap selector to focus on the period and range you care about. Outlier-capped designs are dimmed in the table and excluded from per-editor averages and medians.

Drilling into one editor's designs

In the By editor view, each editor's name is a link. Click it to open a dialog titled Designs by {editor name} — described as "Designs this editor worked on in the selected window. Click any design to open it in the editor (new tab)." The dialog lists every design that editor worked on during the time range and cap you have selected, so you can audit their work or review it for training.

Each design in the dialog shows its active time and its send outcome — a label for where it was sent (GFcrew, Dropbox, Webhook, or Preset), or Not sent if it was closed without sending. Designs created before activity tracking was introduced are flagged est. ("Pre-beacon design — wall-clock estimate, not measured active time") because their time is a wall-clock estimate rather than measured active time. Click any design to open it in the editor in a new tab.

Related articles

• Pay-as-you-go pricing: how renders are billed
• Sending overview: how delivery works
• Send To: destinations and presets
• Studio overview
• Auto-refill: keeping your balance topped up