Atlassian is still health-checking the Connect app you migrated to Forge

Key takeaways

• Monitoring is tied to APP VERSIONS, not to the app's current framework — publishing a Forge version does not retire the probes on Connect versions that still have live installations.
• It stops on its own ONLY when the last Connect install goes. Atlassian staff: 'After migration, the monitoring doesn't stop automatically.' Otherwise you must ask.
• The 99.9% 28-day SLO is applied to each app base URL INDIVIDUALLY, so a decommissioned Connect URL becomes its own failing target.
• Redirecting the old base URL does not help: 'HTTP redirections won't be followed.' Only a 200, within 3 seconds, counts.
• Forge apps are not probed this way at all — reliability is measured on invocation success and latency instead.

If you have migrated a Cloud Fortified app from Connect to Forge and your logs still show requests to /atlassian-connect.json, nothing is broken. The user agent will read Atlassian-CFA-healthcheck, and it is doing exactly what it was designed to do.

The reason is worth internalising, because the obvious mental model is wrong and the correction has a bill attached.

Monitoring is bound to versions, not to frameworks

The instinct is that Cloud Fortified monitors your app — one thing, with a current shape. It does not. It monitors app versions, and versions do not stop existing because you published a newer one on a different framework.

Ankur Yarazarvi of Atlassian answered this on the developer community on 18 June 2026, in the reply Atlassian marked as the accepted answer, and the wording is unusually clear:

"Yes. Cloud Fortified availability monitoring (via the 'pollinator' system) continues to probe the healthcheck URL for any Connect versions that still have active installations. Monitoring is tied to app versions, not the app's current framework—so even after publishing a Forge version, older Connect versions with remaining installations will continue to be monitored."

So the probes are not a leftover, a bug, or a Forge Remote misconfiguration. As long as one customer is still on a Connect version, that version's base URL is a live monitored target.

The public documentation says the same thing from the other direction, in the requirements that took effect in April 2023:

"All app base URLs that receive customer traffic will be monitored, including the latest version of the app. [sic] the last patch version for each minor version with installations, and all regions for app versions that support data residency."

Each of those is a monitored target in its own right.

The part that costs money

Here is the sentence that turns this from trivia into an operational problem, from the same requirements:

"The 99.9% 28-day target SLO will be applied to each app base URL individually."

Individually. Not averaged across your estate, not weighted by installs. A Connect base URL you switched off is not diluted by your healthy Forge traffic — it is its own target, sitting at zero, over a rolling 28 days. The documentation puts that budget at "approximately 40 minutes of downtime per month", which matches the arithmetic — 0.1% of 28 days is 40.32 minutes. An endpoint that is simply gone exhausts that inside an hour, and then keeps failing for the whole 28-day window.

And the fix most people reach for first does not work:

"Only the HTTP status code 200 OK will be accepted. An HTTP response must be returned within 3 seconds. HTTP redirections won't be followed."

Redirecting the old Connect base URL to the new one is the natural tidy-up when you decommission a service. It will not satisfy this check: a 301 or 302 is not a 200, and the prober will not follow it. Nor will a 200 that takes four seconds to arrive.

One caveat, because the page disagrees with itself and I would rather flag that than paper over it. The requirement above says "Only the HTTP status code 200 OK will be accepted", but a few lines later the event definitions say a good event is one "that returns an HTTP response with a 2xx Successful status code". Those cannot both be true for a 204. I do not know which one the prober implements, and neither sentence is hedged, so if your health check returns anything in the 2xx range other than a plain 200, that is worth resolving with Atlassian rather than assuming.

So the safe sequence during a migration is the boring one: keep the old health-check endpoint alive and returning 200 until the monitoring is actually retired, even though the app behind it has moved on. It has stopped being an app endpoint and become a compliance endpoint. That is the same shape as the clean security scan that isn't — two tools disagreeing about the same fact because they are not measuring the same thing.

It does not stop on your schedule

This is the sentence I would put on a sticky note:

"After migration, the monitoring doesn't stop automatically. You'll need to manually request removal of the healthcheck monitoring once Connect installations are fully migrated."

There are two ways it ends. Passively, it stops once every Connect installation has migrated or been removed — which is a schedule set by your customers, not by you, and on a long-tail install base that can run for a very long time. Actively, you ask for it.

There is an alerting side to this as well: the documentation says Atlassian will "notify you if at least 1 app health check request has failed in the last 15 minutes", which is why a dead endpoint is not merely a silent statistic.

The active route is a service-desk request on Atlassian's ecosystem instance — the ERCLOUD desk, raised as a General Question, asking for removal of two distinct things. The staff answer links it directly: ecosystem.atlassian.net/servicedesk/customer/portal/34/group/110/create/654, which needs a Marketplace Partner login.

The health-check URL monitoring for that Connect version's base URL. And your email addresses from the alert system.

Scope that second one carefully, because it is easy to overshoot. The alert address you gave at programme signup is partner-level and fires for all three Connect SLIs — availability, installation callbacks and webhook delivery — so ask for removal against the specific app and version rather than the address wholesale, or you will go quiet on apps that are still live.

What Forge is measured on instead

The natural next question is what replaces it. The same staff answer:

"No. Forge apps (including Forge Remote) are not monitored using the same HTTP healthcheck probing mechanism as Connect apps. Forge reliability is measured differently — using invocation success rates and latency, not synthetic HTTP probes against your backend URLs."

If you run Forge Remote, that is the specific reassurance you were probably looking for: your remotes.baseUrl endpoints are not being synthetically probed. Any Atlassian-CFA-healthcheck traffic you see is aimed at a legacy Connect version, not at your remote backend.

I wrote, in an earlier draft of this piece, that I had gone looking for a Forge-side page documenting that substitute measure and had not found one. That was wrong, and wrong in my own favour, so here is what is actually there.

The metrics exist and are documented. Forge's invocation metrics page defines an invocation success rate — "The percentage of successful vs. failed invocations, across all functions" — and an invocation response time, which is precisely the pair the staff answer named.

What does not exist is a target. The Cloud Fortified reliability requirements page says it outright:

"For Forge Marketplace apps, see Forge metrics. Note, we don't yet have SLIs and SLOs defined for Forge Marketplace apps."

That is the finding, and it is sharper than the hedge I replaced. Migrate off Connect and you do not swap one reliability obligation for another. You keep a 99.9% obligation on the base URL you have stopped using, and you acquire no published target at all on the thing you actually now run. There are Forge metrics to look at; there is nothing yet to breach.

The same page also settles the scoping question the original poster was asking about, in a heading: "Identify or implement a health check resource (for Connect Marketplace apps)". The health check is a Connect instrument, said explicitly, one page over from the availability document that never mentions either framework.

The generalisable bit

The failure here is not really about health checks. It is about a system that binds a behaviour to an artefact you thought you had superseded. You migrated the app; in Atlassian's infrastructure there are still N versions, some Connect, each with its own installations, base URL, regions and individually-assessed SLO. Every consequence above falls out of that mismatch.

The Connect end-of-support timeline is what bounds it in practice, and it is the number worth having in front of you: the long tail is not indefinite, but it is not yours to set either.

One more thing, and it changes the horizon

Everything above is current, and none of it is permanent. Atlassian announced in June that Cloud Fortified is being replaced, and the programme page carries the timeline:

"The Atlassian Enterprise Certified program is open to all Forge cloud apps. The Atlassian Enterprise Certified program will begin onboarding apps in Q3 CY2026. At the time of program onboarding, we will stop accepting new submissions for the Cloud Fortified Apps Program. Cloud Fortified will be phased out by the end of CY2026."

That page was last updated on 21 August 2026, so it is the live position as I write. Two things follow for anyone mid-migration.

The mechanics in this article still apply. The probes are still running, the SLO is still assessed against each base URL, and the service-desk request is still the way to stop it. A programme being wound down does not stop measuring you on the way out.

But the destination has moved, and in a direction that matters here. The successor is "open to all Forge cloud apps" — a different posture from the programme that has no Forge SLOs defined at all. If you are planning migration work around Cloud Fortified compliance specifically, that is worth a conversation with Atlassian before it becomes a year of engineering aimed at a programme that will not exist.

Atlassian-CFA-healthcheck hitting /atlassian-connect.json after a Forge migration is expected behaviour, not a defect. Monitoring is scoped to app versions rather than frameworks, so every Connect version with a live installation keeps its own probe. Each base URL carries its own 99.9% 28-day SLO, redirects are not followed, and only a 200 inside three seconds counts — so keep the old endpoint answering until monitoring is formally retired. Retirement is a manual request on the ERCLOUD desk covering both the URL monitoring and the alert email addresses. And Forge itself is not probed this way at all.

If you are in the middle of one of these migrations, the two things worth doing this week are checking whether anything still resolves at your old Connect base URL, and finding out how many installations are actually left on those versions. The second number is the one that decides whether this ends by itself.