The app is approved and on sale. It can be installed from its Marketplace listing. Approved 20 August 2026.
Known issues, open. Four are below. Three of them affect whether an attachment arrives; the fourth affects only what the panel shows while a sync runs — the files still arrive. The items that affect what the app does with your data are listed in the data processing agreement §14.
Last checked: 21 August 2026
This app runs entirely on Atlassian Forge. We operate no servers of our own, so there is no infrastructure of ours to be up or down. What can break is the app's own code, or one of the two services it depends on.
| Who runs it | Where to check | |
|---|---|---|
| The app itself | IDEAL WORKS | This page |
| Jira Cloud and the Forge platform | Atlassian | status.atlassian.com |
| Intercom®'s API and attachment hosting | Intercom, Inc. | status.intercom.com |
If attachments stop syncing, check those two first. Most of what looks like an outage on our side is one of them, and both publish faster and more accurately than we can.
This page is updated by hand. There is no automated monitoring behind it, and we would rather say so than let the page imply a watch we do not keep. If something is broken and this page still says otherwise, tell us at support@conduitworks.dev — that is the fastest way to get it corrected.
Found: 7 August 2026. Still open. Fix written, ships in the next release.
Intercom serves attachment files from a pool of hosts. The build currently under review declares only part of that pool as a permitted destination, so a file served from one of the undeclared hosts is refused before it can be retrieved.
How it looks: the panel counts the file as failed, not skipped — it shows
N synced, M failed. The failed ones will be retried automatically., and the sync record keeps
the file name and the download error. In this release that sentence never changes. The
download is retried up to five times and then abandoned, but the panel goes on saying the
failures will be retried. If the count has not moved after about an hour, treat them as
permanent.
Who is affected: Files an end customer sent through the Intercom Messenger are the ones to expect this on. Intercom's own integration guidance lists a separate host for Messenger uploads, and that host is not among this release's declarations, so those files are expected to fail consistently rather than now and then. We have not measured which host serves any given file, so we say expected rather than certain. Whether any other file fails depends on which host Intercom used for it, and that is what makes the rest look intermittent.
What to do meanwhile: tell us at support@conduitworks.dev and we will confirm whether this is the cause. There is no workaround inside the app.
Fix: the next release declares the full set of hosts, including Intercom's EU and Australia endpoints. Adding hosts to a Forge app requires each site's administrator to approve the new version, so it will not arrive silently.
Found: 8 August 2026. Still open. Fix written, ships in the next release.
If the app cannot hand an incoming notification to its internal queue, the endpoint answers with an error instead of accepting it. Intercom then discards every notification to that endpoint for fifteen minutes. Nothing appears on the settings screen while this happens — it still shows the last notification it did accept, so the setup looks healthy.
Workaround: open the issue and press Sync attachments. A manual sync reconciles the whole conversation against what is already on the issue, so nothing is lost permanently.
Fix: the next release answers 200 in that case and records it, so the settings screen says what happened.
⚠️ Caveat on the workaround above. If the internal queue is what is failing, the manual button can fail the same way. In this release it then leaves the panel showing Syncing… with the buttons disabled for about twenty minutes rather than reporting an error. Reload and try again after that.
Found: 18 August 2026. Still open. No fix written yet.
To avoid uploading the same file twice, the app ignores a trailing number in brackets when it
compares names: screenshot (2).png is compared as screenshot.png. It cannot tell a number it
added itself from one a person typed.
So if someone has manually attached screenshot (2).png to the issue, and a customer then sends
a screenshot.png of exactly the same byte size, the app treats them as the same file and
skips the customer's one. The panel counts it under skipped, so nothing on screen says which
file was dropped. Files of a different byte size are unaffected.
Workaround: if a customer says they sent a file and it is not on the issue, check whether a file of the same size with a bracketed number is already attached to it. Jira has no rename for attachments — each one offers only Download and Delete — so the way through is to download that existing file, delete it from the issue, and press Sync attachments again. The customer's file then has nothing to collide with and uploads. Re-attach the file you downloaded afterwards if you still need it.
Fix: limit the bracketed-number rule to names the app generated itself. Not written yet, so we are not promising a release for it.
Found: 18 August 2026. Still open. Fix written, ships in the next release.
The panel polls for the result of a sync every three seconds and gives up after forty tries — about two minutes. A sync that takes longer than that keeps running and the files still arrive, but the panel goes on showing Syncing… and never reports how it ended.
This matters more than it sounds, because the app is sold on large files: Intercom allows up to 100 MB per file, and the worker itself is allowed 900 seconds.
Workaround: reopen the issue. The panel then shows the current state.
Fix: the next release polls for as long as the worker is allowed to run — fifteen minutes, not two — slowing from every three seconds to every fifteen after the first minute. If it does reach that limit it stops silently no longer: the panel says the sync has been running for over fifteen minutes, that it may still finish, and offers Check now.
No outages to report. This section records unplanned downtime once it occurs, with what happened, who was affected, and what changed as a result. Known defects live in Open issues above and stay there until they ship a fix.
Once the app is listed, version history will be on its Atlassian Marketplace listing, under Versions. Forge apps are updated by Atlassian without action from you, unless a release changes the permissions the app requests — in that case a Jira site administrator has to approve it before the new version takes effect.