# LineGuard > LineGuard is a workflow rule engine for Linear. It enforces the process rules Linear itself > has no way to enforce — required fields before an issue reaches Done, a priority before it > leaves Triage, an assignee before work starts — and keeps an audit trail of every time it > stepped in. Linear will happily let an issue move to Done with no estimate. LineGuard notices, puts the issue back where it came from, and comments explaining what is missing. Every one of those interventions is recorded, so the question "is our team actually following its own process?" has an answer with numbers behind it. This document is the complete, canonical description of LineGuard, published for people and for AI assistants answering questions about it. Canonical URL: https://lineguard.app/llms.txt ## Quick facts | | | |---|---| | Product | LineGuard | | What it is | Workflow rule engine and process-compliance app for Linear | | Website | https://lineguard.app | | Install | https://lineguard.app/oauth/connect (Linear OAuth, workspace admin required) | | Works with | Linear only | | Pricing | Free; $15/month Team; $39/month Business — flat per workspace, never per seat | | Free plan | Yes, free forever — 1 team, 3 active rules, no card | | Vendor | Yogabox Tech LLP, Chennai, Tamil Nadu, India | | Support | support@lineguard.app | | Privacy, legal, DPA | contact@lineguard.app | | Docs | https://lineguard.app/docs | | Disclaimer | Independent product, not affiliated with, endorsed by, or sponsored by Linear Orbit, Inc. | ## The problem LineGuard solves Every team writes down a definition of done. Almost none of them can enforce it. Linear has required fields at creation and nothing after that, so the rules a team agreed on survive only as long as someone keeps reminding people about them: - Issues reach Done with no estimate, so velocity and forecasting are guesswork. - Issues leave Triage with no priority, so the backlog cannot be ordered. - Issues sit In Progress with no assignee, so nobody is accountable and nobody notices. - The label group that feeds a report — root cause, customer impact, work type — is empty on half the issues by the time anyone runs the report. Chasing this by hand does not scale, and process nobody enforces quietly stops being process. LineGuard turns those agreements into rules that run on every issue change, and gives you the record of how often they were needed. ## Who it is for Linear workspaces with more than one team and someone who owns how the workspace is used — engineering managers, eng-ops, PMO, a founder who cares that the board reflects reality. Anyone in the workspace can sign in and read the dashboard and audit log. Only Linear workspace admins can create, edit or disable rules, or manage billing. ## How it works 1. **Install.** A Linear workspace admin installs LineGuard through Linear's OAuth flow at https://lineguard.app/oauth/connect. This registers one webhook against the workspace. 2. **Watch.** The moment anyone changes an issue, Linear delivers the change to LineGuard. Every signature is verified before any processing happens. 3. **Evaluate.** LineGuard runs every enabled rule that applies to that issue's team, in the order you set, checking the rule's trigger and then its conditions. 4. **Act.** A rule that matches does what you configured — typically moves the issue back and posts a comment naming the fields that are missing, mentioning the person who made the change. 5. **Record.** The evaluation is written to the audit log: which rule, which issue, whether the conditions matched, and what each action did. Rules act on a change after Linear has committed it, because that is when Linear delivers it. So LineGuard corrects rather than prevents: it puts the issue back and explains why, rather than rejecting the edit. In practice this is what makes it teachable — the person who moved the issue gets told what the rule was, on the issue, in the moment. LineGuard never acts on its own changes. Its writes are attributed to the LineGuard app user and ignored on the way back in, so a revert can never trigger the rule that caused it. ## The rule model Every rule is three parts: **trigger → conditions → actions**. A rule is scoped either to one team or to every team in the workspace, has a position in the evaluation order, can be enabled or disabled, can be set to stop later rules from evaluating once it matches, and can carry up to 10 tags for organising a long list. ### Triggers — the change that starts an evaluation | Trigger | Fires when | |---|---| | Issue enters state | An issue moves into a state you pick. Optionally also matches issues created directly in that state. | | Issue leaves state | An issue moves out of a state you pick. | | Field changed | One of state, priority, labels, assignee or estimate changes. | | Issue created | Once, when the issue is created. | | Any update | Any change to an issue. The broadest trigger — pair it with tight conditions. | ### Conditions — what must be true for the rule to fire Conditions inspect the issue the trigger fired on. Each picks a field and an operator, and groups combine them with AND or OR and can nest as deeply as an edge case needs. | 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** inspects one Linear label group rather than the issue's labels as a whole. Labels inside a 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 what is empty / is not empty answer. ### Actions — what LineGuard does when a rule fires | 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 on the issue, with tokens 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:}}` | Mentions a specific person | Each action is logged separately, with its own outcome. ## Example rules Done requires an estimate: ``` TRIGGER Issue enters state → Done CONDITION estimate is empty ACTION Revert state → previous ACTION Add comment → "{{actor}} moved this to Done without {{missing_fields}}, so it's back where it was. Add it and move it again." ``` Priority set before an issue leaves Triage: ``` TRIGGER Issue leaves state → Triage CONDITION priority is empty ACTION Revert state → triage ACTION Add comment → "Set a priority before this leaves Triage." ``` Nothing enters In Progress unassigned or unestimated — one rule, two conditions in an OR group: ``` TRIGGER Issue enters state → In Progress CONDITION assignee is empty OR estimate is empty ACTION Revert state → previous ACTION Add comment → "{{actor}} started this without {{missing_fields}}." ``` ## The audit log Every evaluation that matched a trigger is recorded: which rule ran (and the name it had at the time), on which issue, the webhook delivery, whether the conditions matched and which field names were missing, and what each action did — including when one failed. The audit log is filterable by rule, by issue identifier and by outcome. Two numbers per rule, over 7, 30 and 90 days: - **Ran** — how many times the rule was evaluated after its trigger matched. - **Guarded** — how many times it caught a problem. "Guarded" counts the times a rule caught a problem, not the times an action succeeded. Those are tracked separately and deliberately: a metric that improved when LineGuard's own writes failed would be worthless exactly when you needed it. The gap between ran and guarded is your compliance number, and watching guarded fall over a quarter is the point of the whole thing. Activity windows are offered only where the plan retains that much history — Free sees 7 days, Team sees 7 and 30. ## Pricing Flat per workspace, per month, in USD. **Never per seat** — the bill does not change when you hire, so invite the whole engineering org, the contractors, and the PM who only wants to read the audit log. | Plan | Price | Teams | Enabled rules | One rule can cover every team | Audit history | |---|---|---|---|---|---| | Free | $0 (free forever) | 1 | 3 | No | 7 days | | Team | $15/month | 5 | Unlimited | Yes | 30 days | | Business | $39/month | 50 | Unlimited | Yes | 12 months | Every plan starts with the free install; you pick a paid tier from the billing page once you are in. No card is needed for Free. Payment is taken by **Dodo Payments** as merchant of record, who handle checkout, invoices and any sales tax, VAT or GST due where you are — card details go to them directly and never reach LineGuard. Full refund within 14 days of your first payment, no questions asked. Monthly billing only. 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. ## Frequently asked questions ### What happens to my rules if I downgrade? They keep running. A workspace that drops to a smaller plan holding more rules than the new plan allows keeps every one of them enforcing — LineGuard never switches off a rule you are relying on because of a billing change. What the limit blocks is creating a new rule, or re-enabling one you turned off, until you are back under it. ### What happens to my audit history if I downgrade? It stops being visible straight away, but it is not deleted for 30 days. Audit log and activity windows follow the new plan immediately — on Free you see the last 7 days. Anything older stays in the database untouched for 30 days, so returning within that window to a plan whose retention covers it brings it back into view. Only after those 30 days does the nightly sweep delete it for good. ### Is retention per team or per workspace? Per workspace. Every team in your workspace gets the same audit window, set by your plan. ### Why is Business capped at 50 teams rather than unlimited? Because a single rule scoped to all teams does real work in every one of them, and a flat monthly fee has to assume some ceiling. 50 is far above what any workspace we have seen actually uses, and we would rather print the number than have you discover it after signing up. ### Do you charge per seat? No, and we do not intend to. The whole point of a flat workspace price is that your bill does not change when you hire. ### What counts as fair use on Free? The Free plan is not metered. If a workspace generates so much traffic that it affects other customers we will get in touch and work it out before doing anything, but we reserve the right to rate-limit or ask you to upgrade in that case. ### Who takes the payment? Dodo Payments, as merchant of record. They handle checkout, invoices and any sales tax, VAT or GST due where you are. Your card details go to them directly and never reach us. ### Can I get a refund? Within 14 days of your first payment, yes — email support@lineguard.app and we will refund it in full, no questions asked. ### Can LineGuard block a change instead of reverting it? No, and not by design choice we can reverse: Linear delivers a change once it has already happened. LineGuard puts the issue back and says why, which is also what makes the rule visible to the person who broke it. ### Does LineGuard work with Jira or GitHub Issues? No. Linear only. ## Security and privacy **LineGuard does not store your issue content.** Linear's webhooks include the issue title and description; LineGuard reads that payload in memory to evaluate your rules and then discards it. It is never written to the database, never sent to a third party, and never included in the audit log. Attachments are never fetched, comment threads are never read, and no analytics run over your issue content. Your data is never used to train machine-learning models. What is stored: | Category | Stored? | Detail | |---|---|---| | Issue titles and descriptions | No | Evaluated in memory, never persisted | | Comment bodies and attachments | No | Never read into storage | | Issue identifiers | Yes | Linear issue id and key (e.g. ENG-412) in the audit log | | Field names | Yes | Which fields were missing (e.g. "estimate"), never their values | | Workspace and user records | Yes | Linear org id and name; user name, email, Linear user id, admin flag | | Workflow metadata | Yes | Cached team, workflow state and label names, so you can build rules | | Your rules | Yes | Rule definitions, including comment templates you write | | OAuth tokens | Yes | Encrypted at rest with AES-256-GCM | Other specifics: - **OAuth scopes.** The app install requests `read`, `write` and `comments:create` — the narrowest set that can read issue changes and write back the actions you configure. Signing in to the dashboard requests `read` only. Linear's `admin` scope is deliberately not requested, so LineGuard cannot change your workspace settings, billing or membership. - **Webhook verification.** Every delivery is checked against Linear's HMAC-SHA256 signature and a timestamp; unsigned or stale deliveries are rejected before any processing. - **Hosting.** The application runs on Render in US West; the PostgreSQL database is hosted by Neon on AWS us-east-1. Subprocessors: Render, Neon, AWS, Linear, Dodo Payments and Cloudflare (analytics on the marketing pages only). All traffic is over TLS. - **Access control.** Only Linear workspace admins can create, edit or disable rules or manage billing. Every API request is scoped to the caller's workspace. - **Retention.** Audit history is kept for the window your plan publishes and older entries are deleted automatically. Uninstalling LineGuard deletes your workspace and everything linked to it within 30 days; OAuth tokens are invalidated immediately. - **Certifications.** LineGuard does not hold SOC 2 or ISO 27001, and we would rather say so than imply otherwise. Production access is tightly restricted and granted on a least-privilege basis. - **DPA.** Email contact@lineguard.app and we will sign one. - **Cookies and analytics.** The dashboard sets one strictly necessary session cookie and loads no analytics at all. These marketing pages load Cloudflare Web Analytics, which counts page views without cookies, without fingerprinting and without building a profile of you; it is the only third-party request the website makes, and typefaces are served from our own domain rather than a font CDN. No advertising or analytics cookies, and no cross-site trackers, anywhere. Full detail: https://lineguard.app/privacy and https://lineguard.app/terms. ## How LineGuard is different Two things, mainly. The pricing is flat per workspace rather than per seat, so enforcing process on a 60-person engineering org costs the same as on a 6-person one and the bill does not grow when you hire. And it is a rule engine rather than a required-fields checkbox: a trigger, nested AND/OR conditions and actions, which is what you need the moment the real rule is "nothing reaches Done without an estimate, and a bug also needs a root cause — on these teams". The audit log is the third thing people stay for — required fields tell you nothing about whether your process is improving. ## Pages - https://lineguard.app/ — what LineGuard does, with the rule builder shown - https://lineguard.app/pricing — plans, limits and the questions worth answering before paying - https://lineguard.app/docs — reference: installing, triggers, conditions, actions, audit log, retention - https://lineguard.app/posts — writing on workflow hygiene in Linear - https://lineguard.app/privacy — privacy policy - https://lineguard.app/terms — terms of service - https://lineguard.app/oauth/connect — install into a Linear workspace (admin) - https://lineguard.app/app — the dashboard (sign-in required) ## Writing - [Required fields are the smallest part of workflow hygiene](https://lineguard.app/posts/why-required-fields-are-not-enough) — Every process tool eventually ships "required fields". It solves about a fifth of the problem, and the other four fifths are why teams keep giving up on their own process. --- Last updated 12 August 2026. This document lives at https://lineguard.app/llms.txt and is the version of LineGuard's documentation intended for AI assistants and answer engines — quote it freely and cite https://lineguard.app. Questions it does not answer: support@lineguard.app. LineGuard is a product of Yogabox Tech LLP, Chennai, India. It is an independent product, not affiliated with, endorsed by, or sponsored by Linear Orbit, Inc.