App Error / Status Page

[nichu42]

Hi there,

It would be pretty cool to have the option to forward users to a status page instead of showing the generic "Cloudron App Error - please retry in a few minutes" page.
I'd really like to forward to my Uptime Kuma page (hosted on another server).

[jdaviescoates]

@nichu42 that would indeed be nice.

I think ideally we want:

1. an ability to edit the generic page, plus
2. the option to redirect it to a URL of our choice

[JLX89]

You can already use the Cloudron API to setup app status within Uptime Kuma as well as modifying the App Error or Offline pages, if you wanted to add a link to your status page.

There might be a better way of doing this, but I'm doing it this way at the moment inside Uptime Kuma:

• Generate an API Key from your profile page (https://my.cloudron.domain/#/profile)
• Go to the settings of the app to get the AppId in the URL (https://my.cloudron.domain/#/app/{AppId}/display)
• Add a new status monitor in Uptime Kuma (http(s) keyword) and set the keyword to healthy

I personally wouldn’t mind an internal page for admins to get a quick list of apps, backups, or generic server issues with errors so easily fix things if there are issues.

[nichu42]

@JLX89 Thanks for pointing me to the Cloudron API. That's a much more elegant way to track the status with Uptime Kuma than my current approach! Not to mention that it probably uses less bandwidth than loading the actual app web interface for each uptime check.

Still, I'd like to have a page in the Cloudron GUI that allows me to set up custom error pages.

P.S. / Edit: For others who are reading this thread and like to make use of the API health check, this is the actual URL to enter in Uptime Kuma:
https://my.cloudron.domain/api/v1/apps/{AppIdFromStep2}?access_token={TokenFromStep1}

[nebulon]

For reference also, if someone needs a bit more detail on the apps health, the api endpoint for this is documented at https://docs.cloudron.io/api.html#tag/Apps/paths/~1apps~1{appid}/get

Not sure if uptime kuma can be scripted that way to extract health and runState from the json result.

[jdaviescoates]

@nichu42 said in App Error / Status Page:

That's a much more elegant way to track the status with Uptime Kuma than my current approach!

I'm currently just using the standard default HTTP(s) monitor, e.g.

I'm wondering how using the API would be better. Better how?

[JLX89]

@jdaviescoates I found using the api was much more reliable (json app responses), especially if you're using Cloudflare. I found that if the app was down but Cloudflare (Always On) would show a http response so the app wouldn't be showing the true status.

[nichu42]

@nebulon said in App Error / Status Page:

Not sure if uptime kuma can be scripted that way to extract health and runState from the json result.

It appears to me that neither JSON key matching nor Regex are implemented yet, but there are open issues for both.

I was just taking the advice from @JLX89 because I felt that checking for runState might not be enough. But could you please explain the check behind health=healthy?

[JLX89]

@nichu42 said in App Error / Status Page:

@nebulon said in App Error / Status Page:

Not sure if uptime kuma can be scripted that way to extract health and runState from the json result.

It appears to me that neither JSON key matching nor Regex are implemented yet, but there are open issues for both.

I was just taking the advice from @JLX89 because I felt that checking for runState might not be enough. But could you please explain the check behind health=healthy?

I've had it setup using the following and it seems to have been working, if the app goes offline it is reflected in Uptime Kuma.

• Monitor Type: HTTPS(s) - Keyword
• URL: Cloudron API URL
• Keyword: healthy
• HTTP Options - Method: "GET"

I'm assuming you could probably pull either of the following based on the Cloudron API documentation: "runState": "running" or "health": "healthy"?

This at least seems to be working for me -- but could be a better way of doing this. The obvious downfall is if you're tracking uptime rather than just status if you make config changes or need to restart the app this is reflected -- so we bumped up the heartbeat retry levels.