Yep!

Yep!


It's not the cron job. It's this job that's executed by the queue worker.


Although the PHP script that the queue worker is being executed with runs as www-data.

The timestamps match.
It appears that the directories owned by root are created either on the hour or at 45 minutes past the hour. And it seems to be related to those stalled App\Jobs\UpdateFolderCounters job.
Anyone else seeing this behavior?
Having trouble with files in the cache directory under /app/data/storage/framework/cache/data being created with root/root, stalling background jobs and causing frequent disconnects in the frontend.


After changing the user/group for cache/data directory recursively to www-data/www-data, things are working for a moment. Then the same thing happens again. I had a quick go around and couldn't find any obvious misalignment in the configuration or running processes.
This is basically a static web frontend with a simple cron based backend. Hasn't seen any breaking updates in a decade and there are existing docker images for it. No one else interested? 
I've looked through the app development guide and trying to find some time to build some images for cloudron.
Shameless follow up 
Any update on this? Happy to chip in for the implementation.
This was resolved after clearing numerous caches on client and server side. Didn't look further into it.
Apparently it's working on a freshly deployed managed wordpress app. So it's probably something with the htaccess configuration or some plugin related problems.
Hi everyone,
A customer using Safari on Apple iOS 18 is unable to access any apps that rely on the managed WordPress app.
Before I investigate further, could someone try replicating this issue?


Initial test with SSL Test Labs comes back clean:

Yes, this would be great. However, multi-tenancy might present some challenges due to the service ports required by the Unifi Controller, especially for device discovery. That said, as long as L3 adoption is implemented (e.g. via DNS or DHCP option), using a dedicated custom set of ports for each instance should work fine.
See also; https://help.ui.com/hc/en-us/articles/218506997-Required-Ports-Reference
@michaelpope Uptime Kuma caters to a completely different use case, although, there is some overlap e.g. webhook reporting and notification. I am running several instances of both, Uptime Kuma and healthchecks in production 
Yeah, second this.
Wazuh has a great docker image that's maintained by the project itself.
https://documentation.wazuh.com/current/deployment-options/docker/wazuh-container.html
https://github.com/wazuh/wazuh-docker
Smokeping stands out for its ability to provide detailed, long-term network latency and performance monitoring through highly visual, customizable charts, making it an indispensable tool for maintaining network reliability. With Docker images readily available, integrating Smokeping into Cloudronโs app store should be fairly straightforward.
SmokePing is ...
https://oss.oetiker.ch/smokeping/
https://oss.oetiker.ch/smokeping/pub/
https://github.com/oetiker/SmokePing
https://hub.docker.com/r/linuxserver/smokeping
https://hub.docker.com/r/divyavanmahajan/smokeping
https://github.com/jwigley/docker-smokeping-speedtest
Demo:
https://smokeping.oetiker.ch/?target=Customers.OP




This would be a great addition. Tried it once, finding it a bit rough around the edges but the core functionality is definitely there.
@threetrees3 said in Healthchecks.io -- Cron job monitoring:
Just wanted to give a bump for visibility and thank the contributors for getting things going for Healthchecks!
Unfortunately, am not able to contribute in the code wise
Same here, having healthchecks as an app would be awesome! I've got a few instances I am looking to migrate plus, this would make it super easy to spin up dedicated customer instances as needed 
Thanks for all the great work!