Cloudron Forum

Hello everyone,

Thank you all for your support and suggestions throughout this process. I’m happy to report that the issue has been resolved.

After analyzing the resources and following the recommendations provided, we decided to upgrade the AWS instance from t3.large to t3.xlarge. This upgrade provided additional CPU and RAM, which addressed the resource limitations that were causing the server to become unresponsive.

Since the upgrade, we have not experienced any further downtime or performance issues. We can confirm that the problem was related to resource constraints, specifically the depletion of CPU credits and the high reliance on swap memory.

Thank you again for your help and guidance.

Best regards,
Felipe Rubilar

I’ve just cleared the cache, sent a test ticket, and the tickets started coming in again. Two of them were test tickets I sent myself and one is from operations. Thank you for your help — I hope this has resolved the issue at its root. If anything else comes up, I’ll report back in this same thread.

Thanks.

Hello,

I hope you're having a great day. I'm reaching out to you regarding the following matter.

On Thursday, 14/03, users of our Leantime tool, which is hosted on our Cloudron platform, reported encountering issues with opening/downloading files from the application. Please find attached a screenshot illustrating the problem.

We kindly request your assistance in resolving this matter promptly to ensure uninterrupted user productivity.

We look forward to hearing from you.

Best regards,

Dear Support Team,

For the past three weeks, we have been experiencing recurrent issues with our Cloudron instance. Specifically, the system goes down and all the applications hosted on it become unavailable. This has been happening 1-2 times per week during this period.

Each time this issue occurs, we are forced to restart the server on AWS to restore the services and make the applications accessible again. This situation is significantly impacting our organization, as our team members are unable to work with the tools hosted within the Cloudron container during these downtimes.

We have monitored the server resources (CPU, RAM, storage, etc.), and everything appears to be within normal ranges. Unfortunately, we do not have any logs or additional details to identify the root cause of these failures.

We kindly request your assistance in investigating and resolving this issue.

We appreciate your prompt support and look forward to your guidance to prevent further disruptions.

Best regards,
Felipe Rubilar
Cloud Engineer

Hello everyone,

We are running FreeScout on Cloudron, and for about the last 2 hours, our organization has not been receiving any new tickets in our FreeScout helpdesk. Upon checking the system logs, I noticed repeated errors like the following:

POST /polycast/receive HTTP/1.1" 419 21 ...
App details:

FreeScout version: 1.8.197
Cloudron App ID: 99b9ef3d-b524-4349-b7ab-823205ca5f58
Cloudron package version: net.freescout.cloudronapp@1.15.21
Installed at: 26/08/2020
Last updated: 11:58
From what I understand, HTTP 419 errors in Laravel (which FreeScout is based on) are usually related to session or CSRF token issues. However, we have not made any changes to the internal app configuration or the .env file—we only manage the app through the Cloudron dashboard.

So far, I have tried:

Restarting the app from the Cloudron dashboard.
Verifying the incoming mail (IMAP/POP3) configuration in FreeScout.
Testing from different browsers and incognito mode.
Confirming that the server time is correct.
Despite these steps, the issue persists and no new tickets are being received by the helpdesk.

Has anyone experienced this issue or knows how to resolve it?
Is there any internal configuration that needs to be changed, or is this a known bug with FreeScout on Cloudron?

Here is a relevant log snippet:

POST /polycast/receive HTTP/1.1" 419 21 "https://mesa.solutoria.help/"
Any help or guidance would be greatly appreciated!

Best regards,
Felipe Rubilar

Hi again,

Unfortunately, our FreeScout helpdesk has stopped receiving tickets once more.

When I first ran the cache clear command:

sudo -E -u www-data php artisan freescout:clear-cache

it worked correctly for about 1–2 hours — tickets started coming in again during that period. However, after that time window, new incoming tickets stopped being created again.

To temporarily restore service, I had to restart the entire Cloudron server, and after that, tickets began arriving again. Even so, the behavior is still intermittent and not stable.

I also noticed a Cloudron notification that might be relevant:

Server is running out of disk space
One or more file systems are running low on space. Please increase the disk size at the earliest.

/dev/nvme0n1p1 (ext4) mounted at / is at 91% capacity.
Used: 350.66GB
Available: 37.02GB
Size: 387.69GB

I’m not sure if this disk space issue could be causing FreeScout to stop processing incoming emails/tickets, but I wanted to mention it in case it’s related to the 419 errors or to the mail processing queue.

Do you think low disk space on the server could be affecting FreeScout’s ability to handle incoming mail, or is there anything else I should check (logs, queues, cron, etc.) on the Freescout/Cloudron side?

Thanks again for your support — I’ll share any new findings here in the same thread.