ID: 131485491
When Running a Custom Report (ReportID=2160795) for my Troop, it “runs” for about 20-30 seconds, and then fails with an HTTP 504 error (as attached). I have attempted in Chrome, Safari and Firefox and all fail with the same error. I’ve been experiencing this for the last 3-4 weeks.
Any help in this matter will be greatly appreciated.
@RamonNegron - what are the details of the report and the ref number at the lower left
@Stephen_Hornak
I don’t see any reference number for this, but here is the URL for the report that times out:
Below are the settings I’m running the report with:
I also ran a capture and have the details of the capture (in case it helps you out). While running the failure through Gemini, it gives me the below details:
Root Cause: The request is failing because of a 504 Gateway Timeout. The upstream application server failed to generate the report within the 32-second window allowed by the Nginx proxy. The response body contains a generic Chrome error page rather than the expected report data, confirming the connection was severed by the infrastructure before the task completed.
Suggestions:
- Reduce Report Scope: If possible, apply more restrictive filters (e.g., date ranges or specific sub-organizations) to reduce the server-side processing time.
- Retry the Request: Temporary server load can cause intermittent timeouts; a manual refresh may resolve it if the server is currently under heavy load.
- Increase Server Timeouts: If you have control over the infrastructure, increase the
proxy_read_timeout in the Nginx configuration and the corresponding execution limits in the ASP.NET application.
- Asynchronous Processing: Modify the application to generate large reports in the background and notify the user via a webhook or polling mechanism rather than a synchronous HTTP request.
Please let me know if you need any additional details.
@RamonNegron - is this by any chance for troop webhost ?
Expanding on Stephen’s question, it is not uncommon for very large reports (like full exports) to fail due to a server timeout, since the system isn’t designed around exporting the entire database. However, for particularly large units, some otherwise reasonable reports can still fail. Typically, I’ve broken those types of report down by subunit (den or patrol), duplicated it for each subsequent subunit, then run the reports that way.
Thanks @CharleyHamilton
I can definitely try that to see if it helps.
@RamonNegron - the issue is that the process that TWH outlines request far more data than is really needed. You could try the quick export. Or remove some of the options like empty reqs, scout image, emblem icons etc. This is more of a TWH issue in what they are expecting units to do.
Looks like I’ll have to play around with the Report Settings. With the current fields, running it with less Scouts worked (3 Scouts). I’ll keep playing with this and remove “unnecessary” fields.
Thanks for the guidance and quick help!
Yep! Agree @Stephen_Hornak
Thanks again!