Cannot Install Github for Jira

Hi @Quincy Adler-Colvin 

The flag strongly points to an environment-level token, session, or stale provisioning state rather than a simple permission oversight. Try these

• Log out of Atlassian completely
• Try clearing the browser cache, cookies, restart and try again installing the app
• Or try incognito mode to install the app
• Check for Existing App Records
  
  1. Go to Jira Settings > Apps > Manage apps.
  2. Expand the filter dropdown and select All apps
  3. Search for GitHub for Jira 
  4. If you see, try select Uninstall.
• Try installing directly from the marketplace app - https://marketplace.atlassian.com/apps/1219592/github-for-atlassian
• If none works and issue still persists, please raise a support ticket with Atlassian https://support.atlassian.com

That situation is a familiar kind of painful! the board says the sprint is fine, but you can feel that PRs are piling up somewhere in review and nobody can point to where. Usually you only find out when the release slips, which is the worst time to find out.
That's the exact gap Everview's Operation View was built to close. It sits on top of Jira and GitHub your repos stay the source of record and reads delivery health straight from the work: every pull request, deploy, and commit, per iteration, nothing self-reported.

What it surfaces:

• PRs bucketed by how long they've sat (fresh, aging, stale, critical) so code stuck in review shows up as an early warning, even when the sprint itself looks healthy.
• All four DORA signals per iteration, including time to restore, derived from your actual deploy stream — never estimated. When nothing's been restored, it shows a dash, not a fake zero.
• Stage timers — sent → seen → approved → merged → deployed — so you see where PRs actually stall, instead of guessing.

It refreshes as GitHub sends events — no manual resync — and every number traces back to the PR, commit, or deploy behind it. Evidence, not a status update.


Everview (demo data): delivery health for one iteration, read from GitHub — PR flow, DORA signals, and where PRs stall.

Small easter egg: that lines-of-code skyline behind the panel isn't random the bars are drawn from the Seattle skyline!

Feel free to poke at it on the Atlassian Marketplace: Everview.ai

Hola Quincy,

The 401 “Invalid apiKey” from Atlassian’s feature-flag service is useful evidence, but I wouldn’t treat it by itself as proof that the tenant has a stale Marketplace installation record. There’s a more concrete Atlassian-documented condition worth checking first: Jira Cloud can fail Marketplace app installs with the same “We ran into a little trouble” message when the site doesn’t have an appropriate default product-access group configured. Atlassian documents that here.

I’d check admin.atlassian.com > select the site > Product access > Jira, then confirm that Jira has a normal default access group and that site-admins isn’t being used as the default group. If the default group is missing or incorrectly set, correct that and retry the GitHub for Atlassian installation.

That check is especially relevant because you’ve already confirmed the installer has organization-admin and Jira app-admin access, so this doesn’t appear to be a simple missing admin role.

If the default product-access configuration is already correct, I’d then test whether another free Marketplace app installs successfully. If a second app fails in the same way, that points much more strongly to a site-level Marketplace provisioning problem rather than anything specific to GitHub for Atlassian.

If other apps install normally and only GitHub for Atlassian fails, then I’d go to Apps > Manage your apps and check for any partial GitHub for Atlassian entry, as Viswanathan suggested. If there’s nothing removable there, I’d open an Atlassian Support case with the HAR file and console output, including the failed install request, the 401 response, the app key com.github.integration.production, and the site URL. Atlassian can inspect or clear the backend provisioning state that you can’t access from the UI.

I wouldn’t spend much time repeatedly clearing cookies or using multiple browsers unless Support asks me to. With a reproducible Marketplace installation failure and a backend 401, checking the documented site configuration and then escalating with a HAR is the cleaner path.

Thanks,

James