Polling & dedup

Linear, Jira and GitHub triggers find work by polling: they run their query on an interval and start a run for each matching issue they haven’t processed yet. This page covers the mechanics shared by all three.

Poll intervals

Setting	Value
Poll every (seconds) default	120
Minimum	15 (smaller values are treated as 15)
Scheduler resolution	Jimothy checks every 5 seconds whether a trigger is due
Issues per poll	50 (Linear and GitHub: most recently updated; Jira: in your JQL’s ORDER BY)

A poll that’s still in progress isn’t started again. Disabled (paused) triggers don’t poll. Polling starts when the app launches and continues while Jimothy sits in the tray with its window closed.

Faster polling means more API requests; for near-instant starts, use webhooks in addition to a relaxed poll interval.

Dedup

Each trigger remembers the issues it has already started runs for, keyed by issue key (ENG-123, WEB-45, web-app#42, or the webhook key). An issue that’s already been processed is skipped on every later poll, so a matching issue starts one run per trigger, no matter how long it keeps matching.

Things to know:

• Dedup is per trigger. Two triggers that both match an issue each start a run.
• Dedup applies to webhook deliveries as well, so an issue that arrives by webhook and then shows up in a poll runs once.
• Schedule triggers don’t dedup; every firing is a new run.
• A run’s success or failure doesn’t matter: a failed issue isn’t retried automatically. Use Retry on the run, or forget processed issues (below).
• Dedup state lives in trigger-state.json in the data folder and survives restarts.

Re-running updated issues

Turn on Run again when a processed issue is updated to start a new run when an already-processed issue changes. A new run starts only when all of these are true:

1. the issue still matches the trigger’s filter;
2. its “updated” time (Linear updatedAt, Jira updated, GitHub updated_at) is later than when it last started a run;
3. the previous run for that issue has finished (succeeded, failed or cancelled). While a run is still active, updates are ignored.

Caution

Almost any change counts as an update — including Jimothy’s own write-back comments and transitions. With re-triggering on, an issue that still matches after a run can start another one. Make sure issues leave the filter after a run (move them to a state or remove a label the filter depends on), or keep re-triggering off.

Checking a trigger

Where	Control	What it does
Trigger editor	Preview matching issues	Runs the query with the unsaved settings and shows how many issues match right now and the first eight (key, title, state, labels), or the exact error. Doesn’t start runs. For schedules this button is Validate and checks the cron expression.
Triggers page	Check now	Polls immediately, ignoring the interval, and starts runs for new matches.
Triggers page	Eraser button — Forget processed issues (they will trigger again)	Clears the trigger’s dedup memory and counters. On the next poll every currently matching issue starts a run again.
Triggers page	Toggle	Pauses or resumes the trigger.

Each trigger card on the Triggers page shows its status pill (live, error or paused), a one-line summary of its filter, the pipeline it runs, the account, the poll interval, when it last checked, how many runs it has started and how many issues it has processed.

Before enabling a trigger on a busy tracker

Use Preview matching issues first. When you save an enabled trigger, every issue that matches right now will start a run on the first poll (up to 50). If you only want new issues, tighten the filter first (for example with a fresh label, or JQL like created >= -1d).

Trigger errors

When a poll fails (bad credentials, an invalid JQL query, a missing repository, network errors) or a write-back fails:

• the trigger card shows the error in red and the pill turns error;
• the sidebar’s Triggers item shows a red !;
• the Dashboard’s Triggers card shows the error message;
• a Trigger errors (trigger.error) notification is sent, but only when the message changes, so a trigger failing the same way every two minutes doesn’t flood you.

The next successful poll clears the error. Paused triggers don’t show errors.

Other errors you may see:

Error	Cause
Trigger "X" has no linear account. Pick one in the trigger settings.	The trigger’s account was not set.
Account "Y" is a jira account, not linear	The trigger points at an account of another platform.
Jira trigger needs a JQL query / GitHub trigger needs owner and repo	Required fields are empty.
Trigger "X" — Its pipeline no longer exists	The pipeline the trigger runs was removed. (Jimothy won’t let you delete a pipeline a trigger uses, so this is rare.)
HTTP 401 Unauthorized from api.linear.app: …	The key or token was revoked or expired. Re-sign in on Accounts.