Jira and Keepr: issues arrive as tasks, time goes back as worklogs
What the integration does
One integration connects Jira to one Keepr project. Inbound: an issue created in Jira becomes a task in the Keepr project, moving it into any status in the Done category archives the task, moving it out again restores it, and deleting the issue archives its task. Keepr goes by status category, not status name, so custom workflows need no mapping.
Outbound, Keepr logs tracked time as worklogs. When a time entry on a task linked to a Jira issue is saved for the first time, Keepr creates a worklog on the issue; it updates that worklog when the entry changes and deletes it when the entry is deleted. Only time from the integration's Keepr project is sent. Keepr sends the exact seconds; Jira Cloud stores a worklog in whole minutes, rounded down, and refuses one under a minute.
Recommended on Jira Cloud: the Keepr Jira app
On Jira Cloud, connect through the Keepr Jira app whenever you can. It replaces both the webhook and the API token: nobody pastes a secret into Jira's admin pages, no Jira account has to be set aside for Keepr, and the app sends issue events and writes worklogs itself. Jira Data Center and Server cannot run the app, so they use the webhook route in the steps below.
Create the integration with Jira, Cloud, and “Keepr Jira app” as the connection — Keepr preselects it — and copy the connect code Keepr shows. The code is shown once, works once and expires after 24 hours; “New connect code…” under the integration's Credentials issues another.
A Jira site admin installs the Keepr Jira app (the “Set up the Keepr timer panel in Jira” guide covers installing), or updates it and accepts its new permissions under Apps → Manage apps: writing worklogs is among them. Then, in Jira, Settings → Apps → Keepr: paste the code, optionally limit it to some Jira projects such as ABC, and press Connect. Without a limit, issues from every project on the site become tasks in the one Keepr project. The integration's Credentials section then shows when the app linked and to which site.
Worklogs written through the app show the Keepr app as their author, and the comment names the Keepr member who tracked the time. Logging under each member's own Jira account is planned. The integration itself needs no Ultimate plan; only the timer panel's personal tokens do. Everything else — the three issue actions, how issues are matched, what is sent and when — works as described below.
An integration on the webhook can switch: “Switch to the Jira app…” on its page removes the stored API token and shows a connect code. Keep the Jira webhook until the app is linked, then delete it. The reverse switch unlinks the app and shows a new webhook secret for a Jira webhook.
Before you start
In Keepr you need to be an owner or admin of the organization, or a manager of the workspace that holds the project. Every plan includes integrations: Free runs one at a time, Team three, and Ultimate — trial included — as many as you need.
In Jira you need the Jira administrator permission, since webhooks are set up for the whole site. Jira Cloud and Jira Data Center or Server are both supported; choose the edition when creating the integration, because they sign deliveries and sign in differently.
An in-house Jira must reach over HTTPS (outbound, port 443), and Keepr must reach it back over the public internet to log time. There is no VPN or relay.
1. Create the integration in Keepr
Open Organization settings → Integrations and press “New integration”. Choose Jira and its edition, Cloud or Data Center, the Keepr project its tasks go into, and the name it acts under: Keepr shows its actions as, for example, “Archived by Jira · Website”.
Keepr then shows the webhook signing secret, once. Copy it before closing the dialog. Afterwards only its first characters are shown; if it is lost, rotate it on the integration's page and paste the new one into Jira.
2. Add the webhook in Jira
Jira Cloud: open Settings → System → WebHooks, at , and press “Create a WebHook”. Paste the endpoint from the integration's Inbound webhooks section into URL and the signing secret into Secret, then tick Issue created, updated and deleted under Events.
Jira's webhooks cover the whole site, so limit this one to your project with a JQL filter such as . Without one, every project's issues become tasks in the one Keepr project.
Data Center and Server: open Administration → System → WebHooks, at . Jira 11.0 and later have the Secret field; paste the secret there. Older versions and Server cannot sign deliveries, so append and the secret to the URL instead. Keepr accepts that token only from a Data Center integration, and only when a delivery is not signed.
3. Choose who the time is logged as
Jira records every worklog as written by the account whose credential Keepr uses, so in Jira's reports that account appears to have logged all of the team's time. The worklog comment names the Keepr member who tracked it. Logging under each member's own account is planned; until then, use a dedicated Jira account for Keepr rather than a person's.
That account needs to browse the project, log work on its issues, and edit and delete its own worklogs: the Browse projects, Work on issues, Edit own worklogs and Delete own worklogs permissions. On Cloud it takes a Jira license, like any user.
Jira Cloud signs in with the account's email and an API token. Signed in as that account, create the token at Atlassian account → Security → API tokens; Keepr calls Jira's REST API v3 with it.
Data Center and Server sign in with a personal access token. Signed in as that account, create one under Profile → Personal Access Tokens, at ; Keepr sends it as a Bearer token to the REST API v2.
4. Give Keepr the address and the credential
On the integration's page, open Credentials and press “Set…” next to the Jira credential. For Cloud the Jira site URL is ; paste any page of the site and Keepr saves the site address. For Data Center it is your Jira's HTTPS address with its context path, if any, such as /jira; an atlassian.net address is Cloud and is refused there. For Cloud, enter the account's email as well as the API token; Data Center takes the personal access token alone.
Keepr stores the credential encrypted and afterwards shows only its first characters. Switching the edition removes the stored credential, since Cloud and Data Center sign in differently, so set a new one in the same step.
What Keepr sends
An entry is sent once it is finished — a running timer sends nothing until it stops — and only when its task is in the integration's project and links to an issue on that Jira: , or a board or backlog page with the issue open (), whatever the letter case. Tasks the integration created link that way, and so do tasks started from the browser extension on a Jira issue.
The worklog carries the entry's start and its duration (on Cloud in whole minutes, rounded down), and a comment naming the member; Cloud writes the comment in Atlassian's document format, Data Center as plain text. An edit updates the same worklog, deleting the entry deletes it, and moving the entry to another issue moves the worklog there.
Imported time is history and is never sent. The integration's “Recently sent” list shows the latest entries, each with its item, the member, the time Keepr sent, and whether the last send worked; a failed row says why and what to do.
Pause, rotate or revoke
The switch on the integration's page turns it off without losing anything. While it is off, deliveries are recorded but not acted on (Jira does not resend them, so changes made in Jira meanwhile are not caught up), and no time is sent: an entry saved during the pause is sent the next time it changes. Switching it back on takes a slot under your plan's limit again.
“Rotate…” in Credentials replaces the webhook secret at once, with no grace period: deliveries fail until the new secret is in Jira. “Remove” next to the Jira credential stops time reporting and leaves the inbound direction alone.
Revoke is final. Keepr destroys both secrets and acts on nothing more; the integration stays in the list as history, and what it did stays attributed to it in the audit log and on archived tasks. Revoke the token in Jira as well.
When a webhook is not possible
If you cannot add a webhook — no Jira administrator, or a Jira that cannot reach Keepr — an Automation rule can create the tasks through the REST API instead. It needs a personal API token, which is part of the Ultimate plan: create one under API tokens with the timers:write scope. On Cloud, rules live at , or under a project's Project settings → Automation; Data Center has Automation for Jira with the same trigger and action.
Use the trigger “Work item created” (“Issue created” on Data Center) and the action “Send web request”: method POST to , a header Authorization with the value “Bearer” and the token, and a custom JSON body with externalKey , name , url and your projectId. Keepr returns the existing task or creates it, matched exactly as a webhook-created one is.
To archive on Done, a rule on “Work item transitioned” (“Issue transitioned”) makes the same request, ticks “Delay execution of subsequent rule actions until we've received a response”, and then calls with as the task id, which needs the projects:write scope. Every field is in the API reference at api.keepr.ru/docs. Worklogs need no webhook and work either way once the address and credential are set.
If something goes wrong
Every delivery Keepr receives appears under the integration's recent deliveries with what it did. If nothing appears, Jira's request never arrived: check the webhook's URL and, on Data Center, the ?token= value, and whether your Jira can reach . A status change inside one category — To Do to In Progress — is recorded and does nothing; only entering or leaving Done archives or restores.
In “Recently sent”, “Address or credential not set” means the integration has no Jira address or credential yet. “Credential rejected” means Jira refused the API token or personal access token: it was revoked or expired, the Cloud email is not the token's account, or the account lost access, which on Data Center includes a missing Work on issues permission. “Issue not found” means the issue was deleted or the account cannot see it, and “Address not allowed” that the Jira address is not public HTTPS. “Tool refused it” means Jira refused the worklog itself: time tracking switched off, or on Cloud an entry under a minute or an account without the Work on issues permission. “Tool unreachable, retrying” clears on its own once Jira answers.
A send that failed for good is tried again the next time the entry changes.