Connecting Jira to Landfall
Jira lets a person turn a follow-up from an incident into a Jira ticket with one click, and lets the room see how that ticket is going. Landfall creates a ticket only when a person asks for it, and it never edits a ticket afterwards.
- Create (optional): on the postmortem page, a follow-up has a Create in Jira button. Each click is one person approving one ticket. There is no automatic creation, no rule that creates tickets for you and no standing approval.
- Status comes back: Landfall checks the ticket every ten minutes and shows Jira's status next to the follow-up. When Jira marks the ticket done, the follow-up is marked done. Status flows from Jira to Landfall only.
- Read by agents: not through the signal catalog. Beacon and joined agents do not query Jira. They see the follow-ups themselves, and the next similar incident shows which of them are still open.
What you'll need
- A Jira Cloud site, and a Jira account that can create issues in one project.
- An admin on your Landfall organization.
- Nothing to open on your network: Landfall calls your Jira site from its own servers.
1. Create an API token in Atlassian
id.atlassian.com → Security → API tokens
Sign in to id.atlassian.com as the account Landfall should act as, open Security, then API tokens.
Create API token
Give it a name you will recognise, for example landfall-follow-ups, and copy the token. Atlassian shows it once. Tickets Landfall creates appear as created by this account.
2. Connect Jira in Landfall
In Landfall, open Integrations, choose Jira and fill in:
- Site URL: your site's address, for example https://yourcompany.atlassian.net. Just the address, with no path and no query.
- Email: the email of the account that owns the token.
- API token: the token from step 1. It is stored in Landfall's secret store and never shown again.
- Project key: the project tickets go into, for example OPS. Landfall checks that the project exists before it saves.
- Issue type: defaults to Task. It must exist in that project.
Landfall checks the sign-in and the project when you save, so a mistyped key or token is reported then, not later in an incident.
3. Turn on creating tickets
Creating tickets is off until an admin turns on Allow creating tickets on the connection. Saving the setting is an admin action and is recorded in the audit log. Until then the button on the postmortem page is disabled and says why. The button is also disabled in demo rooms, which never create real tickets, and if your Landfall operator has switched Jira creation off for the whole deployment.
What Landfall sends
Each click creates one issue with:
- a summary and description taken from the follow-up, with a link back to the incident;
- the project and issue type from the connection;
- a label that ties the ticket to its follow-up, so a retry after a crash finds the ticket instead of making a second one.
If the follow-up has an owner, that person's display name is written into the Jira description. It is a name, not an email address or a Jira account assignment. Your Jira site holds it under your own retention rules, and removing a person from Landfall does not remove a name already written into a ticket. Leave the owner empty on a follow-up if its ticket should not carry a name.
How status comes back
Every ten minutes Landfall reads the status of tickets it created whose follow-up is still open or in progress. A change shows on the follow-up ("Jira: In Progress, checked 14:05") and as one line in the room. A ticket in a done status marks the follow-up done. A follow-up someone dropped stays dropped, and a person can reopen a done one.
If Jira stops answering for a ticket (it was deleted, or the token lost access), the follow-up keeps its last known status and says ticket unavailable. Landfall never changes, transitions, comments on or deletes a Jira issue.
What Beacon can read
Nothing through the signal catalog. Jira has no operations in get_signal_catalog or query_signals. Follow-ups reach the next incident differently: when a room opens and a similar past incident had follow-ups still open, the "We have seen this before" card lists them with their owner, status and Jira link.
Opening incidents from Jira
Not supported. Jira is a place follow-ups are tracked, not a source of incidents. To open a war room from an alert or a page, see the PagerDuty or Datadog pages.
Troubleshooting
Save the Jira connection under Integrations first. If you did, open it and run Test connection.
An admin needs to turn on Allow creating tickets on the Jira connection.
The account behind the token cannot see that project, or the key is mistyped. Keys are upper case, for example OPS.
The ticket was deleted, moved to a project the token cannot read, or the token was revoked. Create a new token and save it on the connection.
Reference
| Field | Value |
|---|---|
| Site URL | Required. https, address only (no path, no query). |
| Email and API token | Required. The token is a secret, stored per organization, never displayed back. |
| Project key | Required. Checked against Jira on save. |
| Issue type | Optional. Defaults to Task. |
| Allow creating tickets | Off by default. Admin only, audited. |
| Calls Landfall makes | GET /rest/api/3/myself · GET /rest/api/3/project/{key} · POST /rest/api/3/issue · GET /rest/api/3/search (by label) · GET /rest/api/3/issue/{key} |
| Writes | Only POST /rest/api/3/issue, once per person's click. No updates, transitions, comments or deletes. |
| Status check | Every ten minutes, for tickets whose follow-up is open or in progress. |
| Revoke | Delete the API token under Security → API tokens at id.atlassian.com, and remove the connection in Landfall. Tickets already created stay in Jira. |
See Integrations architecture for how every integration shares this connector shape.