The short version. LineGuard watches your Linear workspace for changes, checks them against rules you write, and acts when a rule matches — for example reverting the issue, leaving a comment explaining why, or both. It acts after a change lands, so it corrects rather than prevents.
A Linear workspace admin installs LineGuard through Linear's OAuth flow. The install registers one webhook against your workspace; from that point every issue change is evaluated against your enabled rules. Exactly which permissions that grants, and which ones we refuse, is the next section.
Anyone in your workspace can sign in and read the dashboard. Only Linear workspace admins can create, edit or disable rules, or manage billing.
There are two separate authorizations, and they are not the same size. Installing LineGuard is done once by a workspace admin and is what grants the app its access. Signing in to the dashboard is per person and is read-only — it can never write anything to Linear, whoever signs in.
| Scope | What Linear grants | What LineGuard uses it for |
|---|---|---|
read | Read issues, teams, workflow states, labels and users. | Evaluating a rule's conditions, and keeping the team/state/label lists in the rule builder current. |
write | Change issues. | One thing only: moving an issue back to a state, for the Revert state action. |
comments:create | Post comments. | The Add comment action. Requested separately from write so comments stay an explicit, visible permission. |
Being straight about how coarse this is. Linear's write
scope is workspace-wide issue write — it does not narrow to "may move an issue back to a
previous state", because Linear has no such scope to grant. So the narrowing is ours, not
Linear's: it comes from the fact that LineGuard ships exactly two actions, reverting a
state and posting a comment, and nothing in the product can do anything else with that
permission. If that distinction matters to you, it should — and you should want it stated
rather than glossed as "minimal access".
What we deliberately do not ask for:
admin — so LineGuard cannot change your workspace
settings, billing, or membership. It is also incompatible with the app-identity install
we use, and we do not need it: the webhook is registered at the application level, not
by an admin API call.
app:assignable and app:mentionable — LineGuard is never
assigned an issue and never @-mentioned, so these would be standing permissions with no
feature behind them.
Actions LineGuard takes are attributed to the LineGuard app user, not to a person, so it is always clear in Linear's own history which changes were ours. Tokens are encrypted at rest with AES-256-GCM and are never logged or shown in the dashboard, and every incoming webhook is checked against Linear's signature before anything is processed — see the Privacy Policy for the rest.
Every rule is three parts, evaluated in order:
A rule is scoped either to one team or to every team in the workspace. Rules run in the order shown on the dashboard, and a rule can be set to stop evaluation of later rules once it matches.
Rules act after the fact. Linear delivers the change to us once it has already happened, so LineGuard cannot block an edit — it can only put the issue back and say so. That is a deliberate limit of building on webhooks, not something we plan to change.
| Trigger | Fires when |
|---|---|
| Issue enters state | Fires when an issue moves into a state you pick. Can optionally also match issues created directly in that state. |
| Issue leaves state | Fires when an issue moves out of a state you pick. |
| Field changed | Fires when one of state, priority, labels, assignee or estimate changes. |
| Issue created | Fires once, when the issue is created. |
| Any update | Fires on any change to an issue. The broadest trigger — pair it with tight conditions. |
A note on Issue created and the create-matching option: Linear sends the creation event before the author has finished filling fields in, so a rule that checks for empty fields on creation will match nearly every new issue. The rule builder warns you when you combine the two.
Conditions inspect the issue the trigger fired on. Each condition picks a field and an operator; groups combine them with AND or OR and can nest.
| Field | Operators |
|---|---|
state | is empty, is not empty, equals, does not equal, is one of |
priority | is empty, is not empty, equals, does not equal, is one of |
assignee | is empty, is not empty, equals, does not equal, is one of |
estimate | is empty, is not empty, equals, does not equal, contains, is one of |
labels | is empty, is not empty, contains |
label group | is empty, is not empty |
Label group is worth explaining. Labels inside a Linear label group are
mutually exclusive on an issue, so a group behaves like a single-select field — which makes
"is one of the Root Cause labels set?" the useful question, and that is exactly what
is empty and is not empty answer. If the group is deleted in
Linear, conditions referencing it stop matching rather than matching everything — an
is empty gate is usually wired to a revert, so treating a vanished group as
empty would fire it on every issue in the workspace. That condition goes quiet instead:
as a rule's only condition or inside an AND group it stops the rule firing, while inside an
OR group a sibling condition can still match and the rule fires without it. The missing
group is never named in the audit log either way — it records the rule's overall condition
result, not which leaf produced it — so the place you will actually notice is the rule
builder, which flags a condition pointing at a label group that no longer exists.
| Action | What it does |
|---|---|
| Revert state | Moves the issue back. Target the previous state, Triage, the first backlog state, or a state you name. |
| Add comment | Posts a comment. Supports the tokens below, including real Linear mentions. |
Comment templates support these tokens:
| Token | Renders as |
|---|---|
{{missing_fields}} | The field names the rule found missing |
{{assignee}} | Mentions the issue's assignee |
{{actor}} | Mentions whoever made the change |
{{creator}} | Mentions the issue's creator |
{{user:<id>}} | Mentions a specific person |
Reverting to previous state needs a state to go back to, which an issue being created does not have — so on a rule that also matches creation, that action will fail and be logged. Pick Triage or the first backlog state if you want the revert to work there too.
LineGuard never acts on its own changes. Actions it takes are attributed to the LineGuard app user and skipped on the way back in, so a revert cannot trigger the rule that caused it.
Every evaluation that matched a trigger is recorded: which rule ran, on which issue, whether the conditions matched, and what each action did — including when an action failed. The dashboard shows per-rule counts over 7, 30 and 90 days — for the windows your plan retains, so Free sees 7 days and Team sees 7 and 30. The audit log itself is filterable by rule and issue.
"Guarded" counts the times a rule caught a problem, not the times our action succeeded. Those are tracked separately, deliberately: a metric that improved when our own writes failed would be worthless exactly when you needed it.
Full prices and limits are on the pricing page. In short: Free is one team, three active rules and rules must target a single team; Team is five teams with unlimited rules; Business is fifty teams with unlimited rules. Pricing is per workspace and never per seat.
Limits apply when you create or re-enable a rule, never while rules are running. A workspace that moves to a smaller plan keeps every rule it already has enforcing — we do not switch off something you depend on because of a billing change. You will be blocked from adding a new rule, or turning a disabled one back on, until you are under the limit.
Audit history is kept for 7 days on Free, 30 days on Team and 12 months on Business. The window applies to the whole workspace, not per team, and older entries are deleted automatically.
A plan change takes effect in two stages. What you can see follows the new plan immediately: move to Free and the audit log and activity windows show the last 7 days from that moment. What is deleted waits 30 days — everything older stays in the database untouched until then, so returning inside that window to a plan whose retention window covers it brings it back into view — going from Business to Free and back to Business restores the year; coming back on Team shows the 30 days that plan includes. After 30 days the nightly sweep removes it permanently. The grace exists so a cancellation never destroys a year of history overnight. Uninstalling deletes everything on the same 30-day clock — see Disconnecting below.
A workspace admin removes LineGuard from Linear, in the workspace settings where installed applications are managed. You do not need to email us, and you do not need to cancel a subscription first — removing the app is enough.
What happens immediately.
What happens to your data.
Reinstalling inside the 30 days brings everything back. The deletion clock starts when the app is removed, and reinstalling stops it — your rules, their order, and whatever audit history your plan still retains are all there again. It is a genuine undo rather than a fresh start. After the 30 days there is nothing left to restore, and reinstalling gives you an empty workspace.
If you want your audit log before it goes, ask us at [email protected] while the workspace still exists — there is no self-serve export in the dashboard today.
Something here wrong or missing? Email [email protected] and we will fix it.