Keelcroft / GitLab Issues Sync for Jira / Support

Support

One monitored address for questions, incidents and data requests: support@keelcroft.com. Support hours are Monday to Friday, 09:00–18:00 IST.

Release guidance dated 30 October 2026, effective upon publication.

Response targets

These are initial-response targets during business hours, not resolution or sync-completion SLAs.

• Critical — security incident, or data written to the wrong project: 1 business day.
• High — sync stopped, or a field written incorrectly: 1 business day.
• Normal — setup, mapping, an isolated error, or a data request: 2 business days.
• Low — feature request or documentation feedback: 5 business days.

What to include

Your Jira Cloud hostname, the Jira project key, the GitLab project path, the approximate time of the problem, the agreement state shown in the reconciliation view, and the Jira issue key and GitLab issue number of an affected pair.

Things you can check first

• Check connection: admin-only read-only project/hook access, required events, TLS and reported disabled state. It creates no issue and does not prove a last delivery or end-to-end availability.
• Repair webhook: repairs an enabled connection using its stored root secret, deriving both hook credentials without resetting mappings, linked pairs or the enable boundary. A paused connection must be enabled instead.
• Expired/denied access: actionable 401/403 failures stop with a failed replayable pair. Replace the token or restore permissions, check/repair, then replay. Provider throttling/transient failures keep bounded retries.
• A pair shows “conflict”: review the field names, mapping problems and policy decisions with Preview, choose the intended source values, then Replay when ready. Preview reads both records but changes no issue, stored baseline or queue; it is not a permissions audit or a reservation.
• A label was not written: unsupported plain labels are reported rather than silently rewritten. Managed priority/custom/workflow labels have separate ownership. A comma-containing label cannot be represented by GitLab's comma-separated write API; correct the source/mapping and replay.
• A status was not written: check the binary state map or the optional explicit workflow-label rules. Missing, multiple, unknown or state-inconsistent workflow labels stop transfer. Workflow labels are not native GitLab custom statuses. Changing workflow rules or their status direction requires Pause sync, no saved webhook and zero linked pairs; contact support before reorganising existing links.
• A milestone/date/weight was refused: use an existing project/group milestone; the app does not create one. Start date requires GitLab 19.1 or later and weight requires Premium or Ultimate. Validate supported Jira field types and date/number values.
• Nothing syncs: check that the connection is enabled, token access is valid and required webhook events are present. Check connection is read-only; the separate setup check creates a disposable issue and attempts to delete it.
• The setup check fails only on webhook access. Managing a project's webhooks needs the Maintainer role in GitLab. A token with the api scope but a lower role can read and write issues yet still cannot create the hook. Note that on GitLab.com, project access tokens need a Premium or Ultimate subscription, so a personal access token is usually the right choice there.
• GitLab reports a disabled webhook: inspect the reported delivery failure and restore access/configuration before testing or repairing. A healthy project/hook check is not proof that a delivery arrived. Invalid present signatures are refused rather than retried as plain tokens.
• A GitLab issue was deleted: GitLab sends no issue-deletion webhook. A later sync/recovery/replay read marks the pair failed and leaves the surviving issue alone; unlink after review.

Creation, backlog and missed changes

Automatic creation must be enabled and match the new-issue/trigger-label rule, Jira JQL, common exclude label and issue-type selection as applicable. Existing linked pairs continue syncing independently of creation filters. For existing unlinked issues, use backlog preview/import in either direction, with open/all scope, label filtering and limits of 25/100/250/500. Imports do not copy historical comments/files.

Import progress reports dispatch, not guaranteed verified creation of every counterpart. Inspect bounded failure reasons carefully because they can contain rejected values. Cancel stops pending creation, not in-flight writes, and does not remove issues already created.

Scheduled recovery runs on a five-minute schedule for existing pairs only, at most ten pair slots per invocation/five per connection, with a 20-second budget for starting new work. Queues, API latency, quotas and installation size affect completion; there is no five-minute completion SLA or automatic discovery of new unlinked issues missed by webhooks.

Comments, files and confidentiality

• New connections default descriptions/comments/files to Both. Existing description settings remain; missing legacy comment/file settings stay Off unless explicitly enabled. Check directions first.
• Only new comments/files after linking qualify. Restricted/internal Jira comments and GitLab internal/system notes are excluded; comment edits/deletions are not mirrored. Five pages of 100 comments/notes per side bound history reads; incomplete histories pause copying. Ten comments per direction/pass are copied, with visible shortening after 30,000 source characters.
• Files must be Jira attachments or GitLab uploads referenced in notes, up to 10 MiB and three per direction/pass. Downloads are buffered before size checks, not malware-scanned. Images in formatted text remain links rather than embedded Jira media, and not all GitLab syntax is preserved.
• For an unknown upload outcome, reconcile the actual destination file before clearing recovery state. Known outcomes retry attribution without reupload; a missing marker or expired claim is not permission to upload again. Durable recovery has no automatic app TTL, is capped at 100 stages per issue and may hold a GitLab upload secret/encoded filename. Send only redacted identifiers to support.
• Confidential GitLab export is blocked by default, even for linked pairs. Explicit opt-in does not set Jira issue security, preserve source audiences or erase old copies. Review destination permissions first; this safeguard is not a write ACL and changes during an in-flight pass can race.

Pause, unlink and removal

Pause sync records disabled state before attempting remote webhook cleanup; it retains the token/settings/links/history and reports a failed cleanup for retry or manual hook removal. Confirmed Unlink removes pair/index entries, not either issue, copied content or all recovery/history. Neither action cancels a write already in flight. Stale pair-recovery jobs do not recreate an unlinked pair, but a fresh qualifying automatic-creation event can relink it; change the rule/trigger label if that is not wanted. There is no general disconnect/delete-connection control. See Data deletion for installation-wide uninstall and external cleanup.

Guided trial setup

Use the setup-help link above for your first pair, automatic-creation rule or backlog preview during the standard Marketplace trial. Include your Jira Cloud hostname, whether you use GitLab.com or a self-managed instance, the projects and the fields/directions that matter. Never email credentials or sensitive issue content.

Receiving-side GitLab.com checks cover fields, comments and imports, with earlier live checks for two-way file bytes, creation, assignees and privacy exclusions. Automated workflow/recovery checks are not self-managed, separate-user permissions, scheduled-runtime or load proof; ask for help evaluating those boundaries rather than assuming them.

Security reports

Send suspected vulnerabilities privately to support@keelcroft.com with the subject line “Security”. Include reproducible steps and impact, but do not access data that does not belong to you.