Create GitHub, Jira or Linear issues from errors

An error is grouped into an Issue in ZipLogger, but the work to fix it is planned somewhere else: a GitHub issue, a Jira ticket, a Linear issue. Copying the title and a link by hand works until someone forgets, and then nobody knows which ticket belongs to which error.

This post shows how to create that ticket from the Issue page, or link one that already exists, what ends up in the ticket, and what this does not do yet.

Where it is

Open an Issue under Issues. The page has a Linked issues card with two buttons:

• Create issue… opens a new issue in GitHub, Jira or Linear.
• Link existing… attaches an issue you already have.

Both need the Editor or Admin role. Everyone in the workspace can see the links.

A new Issue card says "Not linked to an issue in GitHub, Jira, Linear or another tracker." Once linked, each link shows by its key, so the card reads acme/shop#42, SHOP-123 or ENG-7 rather than a long URL.

What goes into the new issue

ZipLogger sends a short summary, never the evidence. For a .NET Issue in the checkout-api service, the body of the created issue reads like this (the values are an example; the lines are the ones ZipLogger writes):

Error tracked by ZipLogger in service "checkout-api".

Issue: NullReferenceException: Object reference not set to an instance of an object.

Where: Shop.Payments.PaymentProcessor.Charge

Seen 1,284 times, first 2026-10-14 09:12 UTC, last 2026-10-15 07:40 UTC.

Releases: first 2.4.1, latest 2.4.2.

Stack trace, occurrences and history: https://app.ziplogger.ai/env/…/issues/…

That is the Issue's title, its service, where it happened (the culprit), how many times it was seen, when it was first and last seen, the first and latest release, and a link back. The Where line is left out when there is no culprit, and the Releases line when no occurrence carried a release.

What it does not send: the raw message of any occurrence, the stack trace, request data, user fields or extras. The title is the Issue's own title, the one on the Issues list, so a team member with access to the tracker but not to ZipLogger sees what broke and how often, and follows the link for the rest. Your tracker might be readable by more people than your error data is, which is why the default is this narrow.

The title of the new issue defaults to the Issue's title. The form has a title field if you want something else.

GitHub

GitHub needs no separate connection. It uses the repositories you already connected for finding the commit that broke production, under Settings → Integrations → Repositories. In Create issue…, pick GitHub and the Repository.

The credential needs one more permission than blame does:

• A fine-grained token: add Issues: Read and write to the token on github.com.
• The ZipLogger GitHub App: it needs Issues: write. An installation that was set up before this feature may still have the old permissions, and has to accept the new one on github.com.

If the permission is missing, GitHub answers 403 and ZipLogger tells you which permission to add, rather than failing quietly.

Jira Cloud

An Admin connects Jira under Settings → Integrations → Issue trackers, with Connect on the Jira row:

1. The site address, such as https://your-site.atlassian.net. Only https is accepted.
2. The e-mail of the Atlassian account that owns the token. That account needs the Create issues permission in the project.
3. An Atlassian API token. Create one at id.atlassian.com → Security → API tokens.
4. Click Save. ZipLogger checks the token against your site before storing anything.
5. Pick the default project from the list that now appears, set an Issue type if new issues should not be a Bug, and save again.

New issues go to the default project with the type Bug unless you set another. If Jira refuses an issue, for example because the project needs a field ZipLogger does not fill in, Jira's own message is shown.

Linear

Also under Settings → Integrations → Issue trackers, an Admin clicks Connect on the Linear row and pastes a Linear API key (lin_api_…). Create a personal API key in Linear → Settings → Security & access. Save once to load your teams, then pick the default team and save again.

Tokens

The Jira token and the Linear key are verified before they are saved, stored encrypted and never shown again. The card identifies them by their last four characters. Connecting and disconnecting are written to the workspace audit log. Disconnect removes the token; links already made stay on their Issues.

Linking an issue that already exists

Sometimes the ticket came first, from a customer report or a QA run. Link existing… takes any https issue URL:

https://github.com/acme/shop/issues/42
https://acme.atlassian.net/browse/SHOP-123
https://linear.app/acme/issue/ENG-7

GitHub, Jira and Linear links are recognised and shown as acme/shop#42, SHOP-123 and ENG-7. A link to any other tracker, GitLab included, is kept as a plain link. An Issue holds up to 20 links, and the same outside issue only once.

Creating, linking and unlinking each add a line to the Issue's history. Removing a link changes nothing in the tracker.

Comments and bulk changes

Two smaller additions that sit next to the links on the same pages:

• Comments. The Issue page has a Comments card, in Markdown: what you found, what you tried, who is on it. The author can edit a comment; the author or an Admin can delete it, which leaves "Comment deleted." in its place so the thread still reads in order.
• Bulk actions. On the Issues list, Editors get a checkbox on each row and a bar with Resolve, Ignore… (no end date, 24 hours, 7 days or 30 days), Reopen, Assign to…, Merge (the others into the first one selected) and Clear. An Issue that changed while you were selecting, or is already in that state, is reported instead of overwritten.

The bulk change is also an API call, for up to 100 Issues at a time:

curl -s -X POST https://app.ziplogger.ai/api/v1/issues/bulk \
  -H "Authorization: Bearer $ZIPLOGGER_TOKEN" -H "Content-Type: application/json" \
  -d '{ "action": "resolve", "ids": ["…", "…"] }'

Each Issue gets its own result: ok, conflict, not_found or skipped. action can be resolve, ignore, reopen or assign.

What it does not do

• No two-way status sync. Closing the GitHub, Jira or Linear issue does not resolve the ZipLogger Issue, and resolving the Issue does not close the ticket. If the bug comes back after a resolve, ZipLogger reopens its own Issue as regressed; the ticket stays as it was.
• No Jira Server or Data Center. Jira Cloud only.
• No GitLab issue creation. A GitLab issue can be linked, not created.
• No automatic tickets. An issue is created when someone clicks Create, not when a new Issue appears. For that, use an Issue alert.

Next step

The Issue trackers section of the docs has the short reference. If you have not set up error tracking yet, the JavaScript error tracking post is a good start, or create a free workspace.