Cloud Fortified availability checks ambiguity during Connect to Forge Remote migration

Forge
,
1

Hi Atlassian team,

We migrated an existing Connect Marketplace app to Forge using Forge Remote, and we’re trying to understand how Cloud Fortified availability monitoring behaves during and after this transition.

Our app previously had a Connect descriptor at:

/atlassian-connect.json

In the Forge version, we now define remote backends in manifest.yml using remotes.baseUrl, including region-specific URLs for data residency.

During a recent backend deployment, we observed short-lived 502 responses in our server logs for requests with:

User-Agent: Atlassian-CFA-healthcheck
Path: /atlassian-connect.json

This appears to have correlated with Cloud Fortified availability alerts. However, Forge apps do not use atlassian-connect.json as their descriptor, so we’re unsure whether this alert is coming from:

  1. A legacy Connect healthcheck still configured for the Marketplace app/version.

  2. A healthcheck for older Connect versions that still have active installations.

  3. A Cloud Fortified check that remains tied to the app’s historical Connect descriptor even after migration.

  4. Something related to Forge Remote availability monitoring, though the path suggests Connect.

The documentation and forum posts seem to leave this unclear:

  • CHANGE-775 says app base URLs and regions are monitored for Cloud Fortified availability.

  • The Forge Cloud Fortified announcement says Forge reliability is handled differently, using invocation success rates and latency.

  • Forge Remote introduces partner-hosted backend URLs, but we could not find a clear statement on whether Cloud Fortified probes Forge Remote remotes.baseUrl endpoints directly, or what SLI/SLO applies to those remotes.

Could Atlassian clarify the following?

  1. For apps migrated from Connect to Forge/Forge Remote, does Cloud Fortified continue to monitor the old Connect healthcheck path?

  2. If older Connect versions still have installations, are their base URLs and healthcheck paths still monitored independently?

  3. Are Forge Remote remotes.baseUrl values directly healthchecked for Cloud Fortified availability?

  4. If yes, what path is used for Forge Remote healthchecks?

  5. If no, what Cloud Fortified reliability metrics apply to Forge Remote backends?

  6. What is the correct process to update or retire the legacy Connect healthcheck path after migration?

  7. Is there a way to identify which app version/framework generated a Cloud Fortified availability alert?

This is important because a Connect-style /atlassian-connect.json healthcheck failure may lead us toward the wrong remediation if the actual production app is now Forge Remote. We want to avoid masking a legacy Connect monitoring issue while still ensuring the Forge Remote backend remains highly available.

Thanks.

Ajay

2

Hey @ajay, thanks for reaching out. My name is Phil Grove, I am the PM for the Cloud Fortified App program. Let me discuss your questions with the team and I will come back to you with some answers. Please bear with me. Cheers, Phil.

3

Thanks for looking into it @PhilipGrove :slight_smile:

4

Hi Ajay,

Many thanks for your patience, here are the responses for your questions, please do let me know if you need any further info regarding Cloud Fortified related questions for Connect to Forge Migration of your apps.

1. Does Cloud Fortified continue monitoring the old Connect healthcheck path after migration?
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.
Important: 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. You can raise the request here - Jira Service Management

2. Are older Connect versions with active installations monitored independently?
Yes. Each Connect version’s base URL and configured healthcheck path are monitored independently. If you see Atlassian-CFA-healthcheck requests to /atlassian-connect.json, these are targeting legacy Connect versions that still have active installations.

3. Are Forge Remote remotes.baseUrl endpoints directly healthchecked for Cloud Fortified availability?
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.

4. What path is used for Forge Remote healthchecks / What Cloud Fortified reliability metrics apply to Forge Remote backends?
Not applicable—as noted above, Forge reliability is tracked via invocation-level metrics (success/failure rates, latency).

5. What is the correct process to update or retire the legacy Connect healthcheck path after migration?
Once all Connect installations are migrated or removed, probing will stop naturally. However, to proactively remove monitoring:

  1. Raise an ERCLOUD service desk ticket (select “General Question” as the issue type)
  2. Request removal of:
    The healthcheck URL monitoring based on the Connect version’s base URL
    Email addresses from the alert system

Regards,

Ankur