Dashboard · 5 min read

Renders & Logs

Every render is recorded in the dashboard with its status, timing, and logs — even though BladePDF never stores your document payloads. Use render history to confirm deliveries, diagnose failures, and correlate PDFs with your own records.

Render history

The Renders page lists recent renders. Each entry shows:

Status and the time it was created.
Source — a local view, raw HTML, or a cloud template.
The API key that made the request.
Your reference and any metadata you attached.
Render duration and output size.

Statuses

Status	Meaning
Queued / Running	Waiting for a concurrency slot, or currently rendering.
Success	The PDF was generated and returned.
Failed	The render could not complete — for example a timeout or an asset that could not be resolved.
Error	An unexpected server-side error occurred.
Canceled	The request was aborted before it finished.

Render detail, logs, and metrics

Opening a render shows its per-render log and timing breakdown. Logs are timestamped and typed (info, warning, error, debug), which makes it easy to see exactly where a slow or failed render spent its time. Typical metrics include:

Metric	What it measures
Queue time	How long the request waited for a concurrency slot.
Render time	Wall-clock time to produce the PDF.
Assets resolved / cached / uploaded	How the asset pipeline handled referenced files.
Blade compile time	Time spent compiling a cloud template.
Output size	Size of the generated PDF.

Retention

Render history and logs are operational records, not an archive — they are removed automatically after a fixed window:

Record	Kept for
Render history entries (status, timings, reference, metadata)	13 months (400 days)
Per-render logs (the timestamped log lines on the detail page)	30 days

A render's detail page keeps working after its logs expire — only the log lines disappear; status, metrics, reference, and metadata stay for the full 13 months. When a history entry expires, any stored PDF attached to it is deleted with it.

Keep long-term records on your side

If you need render outcomes beyond these windows — for accounting or compliance — record them in your own system as they happen, for example from webhook events keyed by your reference.

Correlate with your application

Set reference() to your own identifier (an order id, invoice UUID, and so on) so a render is easy to find later. Every API response also returns an x-request-id header, which matches the request id shown in render history and included in webhook payloads.

PHP

php

 1BladePDF::fromView('pdf.invoice', ['invoice' => $invoice])
 2    ->reference($invoice->uuid)
 3    ->metadata(['tenant_id' => $tenant->id])
 4    ->render()
 5    ->pdf();

Report an issue

If a render failed unexpectedly, use Report issue on its detail page to send the render's context to support. Because payloads are not stored, this shares the request metadata and logs — not your document contents — so the team can investigate.

Payloads are never stored

BladePDF keeps render metadata, logs, and metrics, but not your HTML, context, or generated PDF (unless you opt in with stored PDFs). To reproduce an issue you may be asked for a minimal example.

Debugging renders

When a render behaves unexpectedly, work through it in this order:

Check the render's logs for the first warning or error.
Confirm assets resolved — broken images usually mean an unresolved asset:/// or local path.
Review wait conditions if renders are slow or time out (see Options).
Cross-reference the status against plan limits and the error reference.