Presenton Custom Template 504: Separate Timeouts from Processing Failures
If Presenton returns a 504 while importing a custom PowerPoint template, save the failed request and the backend logs from the same operation before deciding where to investigate. A 504 means a gateway or proxy did not receive a timely upstream response. The status code alone does not establish whether template processing eventually finished. HTTP 504 definition
This guide draws on public issue reports and official documentation. It provides a diagnostic sequence for self-hosted users; we have not reproduced the problem. If you use Cloud or do not manage the server, record the visible error and when it occurred, then leave the server-side checks to the administrator. Official reporting guidance
Identify the step that failed
The official template workflow separates font review, source-slide previews, template creation, and layout generation. A 200 response from a preview request must therefore be interpreted within that request's scope. To establish whether the whole template is ready, check the subsequent generation status and the resulting layouts. Template creation
The reporter in Issue #816 encountered a 504 after the font step. Their example had 12 slides, was approximately 2.36 MB, and failed after about 63 seconds. Reducing the same file to one slide worked. They also reported seeing backend 200 responses while the browser showed a 504. These are observations from one case, not evidence of damaged fonts or a slide-count or file-size limit.
The maintainer asked whether rendering eventually completed after the gateway timed out. The checks below follow that distinction and add a way to keep records from different requests separate.
Match the browser and backend records for one operation
Record the time and time zone when you select Continue. In the browser's developer tools, find the failed request in Network and save its method, path, duration, status code, and error response. Include a request ID if one is available. The request named in #816 was fonts-upload-and-slides-preview; use the actual request name in your installed version. Original diagnostic questions
The following table is a suggested way to interpret the evidence. It does not describe fixes tested for this article.
| What the records show | What you can conclude so far | Next check |
|---|---|---|
| Browser 504, followed by a backend completion record matched to the same preview request | Proxy waiting time and preview duration are the first things to investigate | Inspect the response, preview completeness, and subsequent template-generation status |
| Browser 504, with an explicit rendering error or abnormal process exit in the backend | There is evidence of a processing failure | Save the surrounding error context and narrow the reproduction with a small copy |
| A 200 appears in the logs, but belongs to authentication status, font checking, or another request | It has not been matched to this failure | Match records again using the path, time, and request ID |
| No completion or failure record can be found | The outcome remains unknown | State when observation ended and ask the administrator to check the task and resource state |
An administrator can compare proxy and application logs over the same time window. Note any time-zone or clock differences between machines. Without a request ID, use the time, path, and a clearly isolated operation to narrow the match. A single log line containing 200 is insufficient evidence of success.
Reduce a copy to one slide
Keep the original file intact. In a copy, retain one representative slide and remove confidential text, notes, company branding, and other private content. Preserve the layout and fonts needed for comparison. Record the slide count, size, and outcome for both files. If sanitizing the file makes the symptom disappear, record that too.
Compare the full file and the one-slide copy using the same version and access route. If one slide works, add slides back gradually until you find the smallest set that reproduces the problem. Change one condition at a time; changing fonts, versions, and proxy settings together makes the results difficult to interpret. This is a suggested method for narrowing the input. One slide succeeding establishes only that the two inputs produced different outcomes.
Before testing, check the configured providers and where data goes. A self-hosted installation can still send content to an external model. Do not upload a company presentation or fonts you are not authorized to share just to reproduce an error. Gwarket's explanation of self-hosted data boundaries
Locate the timeout before changing settings
Record the components between the browser and Presenton, such as a reverse proxy, CDN, or tunnel, so the administrator can identify which layer returned the 504. Do not expose an internal port to the public internet or disable authentication for a test.
Failure after roughly a minute is a clue, but timing alone does not identify a setting. For example, Nginx's proxy_read_timeout limits the interval between successive reads from the upstream response, rather than the total duration of that response. The effective configuration still needs to be checked. Nginx documentation
Any test with a longer timeout should be arranged by the administrator after identifying the relevant layer. Compare the same minimal example before and after the change, checking whether it completes the required workflow. The disappearance of the 504 does not by itself verify layout generation or export.
As of October 11, 2026, PR #941 remains Open. It proposes bounded concurrent single-slide tasks for previews. This is an unmerged change proposal, not evidence that a released version has fixed the issue. If you later consider upgrading, review the release notes for your deployment, back up your data, and validate the change in a test environment. Official pre-upgrade checks
Prepare a report for the administrator or upstream project
Copy the fields below. Mark unknown values as unknown rather than guessing.
- Environment and version. Cloud, desktop, or self-hosted; Presenton version or image tag; operating system and browser
- Access route. Whether a proxy, CDN, or tunnel is involved; describe the structure without publishing internal addresses
- Files. Slide counts and sizes for the original and minimal copy; font names; whether additional font files are needed
- Reproduction. Starting step, expected result, actual error, and known conditions under which it previously worked
- Time and request. Time and time zone; method and path; duration, HTTP status, and request ID if available
- Backend outcome. Whether the record matches the same request; last observation time; completed, failed, or still unknown; task or template state
- Resources and attempts. CPU and memory limits and usage, if available; each change tried and its result
- Shareable evidence. A small sanitized example, relevant log excerpts, and an error screenshot; note anything omitted because it cannot be shared
Before submitting, remove API keys, cookies, authorization headers, signed URLs, and private information. Full HAR files, environment files, and production logs may contain these details; do not attach them without review. A public GitHub issue should contain only the minimal material that is safe to publish. If the source file cannot be shared safely, start with a written report. Official safe-reporting requirements