App healthcheck requests will be made to each distinct base URL that receives customer traffic, including the latest version of the app, the last patch version for each minor version with installations, and all regions for app versions that support data residency. The 99.9% 28-day target SLO will be applied to each app base URL individually.
I was wondering what is meant with base URL. Are you looking at the baseUrl as defined in the descriptor? Or each individual module entry?
In our case the base URL is usually just that - the base url and there isnāt anything served at that location so this change will cause an issue if the assumption is that there would be something there.
Yes, we are referring to the baseUrl in the app descriptor. But the URL we use for healthcheck requests is not the base URL itself, but rather the base URL followed by the healthcheck path.
We will obtain the healthcheck path by taking the Health check URL for this app that you provided in your App approval request, and ārelativizingā it against the app descriptor base URL.
All this is only relevant to your app if you have ever changed its base URL.
To comply with the new requirements, the app must now make sure that their healthcheck path (/healthcheck) also corresponds to an endpoint for the base URL for version 1.0.0, since Atlassian will also start checking the URL https://example.com/healthcheck for the App availability metric.
ughā¦ For how long? We donāt have a way of forcing customers to upgrade.
Forcing app vendors to have to maintain legacy infrastructure seems really bad. I understand on paper why you want to do it, however it means that we canāt really add new health check functionality etc. This is bad.
To clarify what I mean - if I fork my code base and move over to a new provider as part of this - there may still be instances pointing to the old version - however theyāre not paying and donāt have an active license (and donāt care about upgrading).
Also - if Iāve managed to move all of my customers off the 1.0 version but the marketplace still has that listed in the historical versions - it wonāt be polled?
Weāre also interested in answers for the Danielās questions here. We have similar (or maybe the same) scenario:
had in the past app hosted on x1.y.z
in the meanwhile weāve upgraded our app from free to paid, and we have moved to another domain (x2.y.z)
we did that domain switch 2 years ago (in an effort to ājettisonā non-paying customers staying on old version) - and since that weāve stayed on the current domain
Should we expect that Atlassian will require us to keep x1.y.z/health_check endpoint running? Even if for 2 years nobody is using that old baseUrl? If yes, here are a few questions from me:
can we mark old versions as āprivateā in Marketplace and make Atlassian skip testing health_check for such versions?
if all customers migrate to the new version, will Atlassian still be testing old health_check baseUrl?
are there any thresholds (request count, date, etc) at exceeding which Atlassian will stop testing old baseUrls?
@danielwester, @stefan_hc we definitely donāt want to force you to maintain every version of your app. What we want to monitor is the versions of apps that are still actively used by our customers.
To clarify what I mean - if I fork my code base and move over to a new provider as part of this - there may still be instances pointing to the old version - however theyāre not paying and donāt have an active license (and donāt care about upgrading).
This is one of the cases which should not be included in the requirements. Itās worth remembering too that we have process for retiring apps which can also be applied to app versions. If, as in your example, you move to a new hosting provider, and you still have customers on an old version with a different set of scopes, you are definitely within your right to request that Atlassian uninstall your app from those sites, relieving you of the requirement to maintain an app healthcheck endpoint for that base URL.
Also - if Iāve managed to move all of my customers off the 1.0 version but the marketplace still has that listed in the historical versions - it wonāt be polled?
If thereāre no usages of this version, it wonāt be included in the requirements (as thereās no customer traffic).
Weāre open to discussing it in detail if needed, just let us know via Marketplace message.
Aye. Makes sense now, thank you for clarifying the things.
How to determine if my app old version still does have some usage? Is it possible to obtain that stats somewhere, i.e. maybe from Marketplace reports? (assume that I no longer maintain app under old domain, so I canāt retrieve the traffic stats from there).
Hello @danielwester
Just a question from my side to make sure I understood this correctly. In the previous version we had this base url: https://example.com/some_value/1.0/. Will the health check URL for this version be: https://example.com/healthcheck or https://example.com/some_value/1.0/healthcheck ?
Hi @ReiPano, since under the changed requirements, healthcheck URLs will always be relative to the appās base URL, in your example the healthcheck URL would be https://example.com/some_value/1.0/healthcheck (where /healthcheck depends on what is specified by the app in the context of Cloud Fortified).
We will also follow up with you on your app approval request about your specific case.
fyi this might save others weeks/months of wasted time because itās clearly not documented publicly or internally so support staff have no idea how to help beyond escalating the ticket.
Atlassianās health check service uses a different IP each time and bizarrely this is the user-agent they send in the request: node-fetch/1.0 (+https://github.com/bitinn/node-fetch)
So if youāre using literally any modern infra then your firewall is going to block the health checks.
Your public endpoints have firewall restrictions on user agent string? Or was it blocked as part of the intrusion detection/protection system or ddos prevention? If so, the healtcheck does not occur that often does it? Why would IDS/IPS or DDOS catch it? There is a lot of questions hereā¦
Iām assuming Cloudflareās firewall is occasionally blocking the health check. All my apps (a lot) are hosted on subdomains with the same root domain.
