--- title: "SLAs" slug: admin/sla url: https://projectri.com/docs/admin/sla section: admin audience: admin app_route: "/[slug]/admin/sla" permissions: [settings.view, settings.workflow] mobile: false updated: 2026-09-08 source: Projectri documentation --- # SLAs Response and resolution targets per ticket severity, counted against the workspace's own working week or around the clock. ![SLAs](https://projectri.com/docs-shots/admin-sla.png) ## What it is How fast support promises to answer, and to finish, for each severity of ticket. A policy sets two targets — a first response and a resolution — and says whether the clock runs only during working hours. ## How to get there **Work → SLAs** in the admin console rail, at `//admin/sla`. Reading the policies needs `settings.view`. Creating, editing and deleting one needs `settings.workflow`. ## How to use it ### Read a policy 1. The card leads with the severity, the policy name, and a **Default** tag when it is the one applied to every new ticket at that severity. 2. Then the two targets and whether it counts business hours only or runs around the clock. 3. Underneath, an example: what a ticket raised right now would be due. It is computed by the server on this workspace's working window, so it is the answer for this moment rather than arithmetic you have to do — and it is the one place you can see that the week the SLA counts is the week you actually keep. 4. A card also says how many tickets are being measured against it. ### Start from the recommended set 1. On an empty screen, press the starter option beside **Create the first policy**. It shows all four policies and every number before anything is written. 2. The set is: **Critical** — respond in 30m, resolve in 4h, around the clock. **High** — respond in 2h, resolve in one working day. **Medium** — respond in 4h, resolve in three working days. **Low** — respond in one working day, resolve in five working days. The last three count business hours only. 3. Working-day targets are converted against **this workspace's own day length** at the moment they are created, so nothing is written until the workspace settings have loaded. 4. Each is created through the ordinary create path, so every validation and the audit trail behave exactly as they do for a hand-written policy. A partial failure is reported as one. ### Write one by hand 1. Press **New policy**. 2. Name it and choose the **severity**. Severity is fixed after creation — it is what a new ticket is matched on, and changing it would silently move two severities at once. 3. Type the two targets as `30m`, `4h` or `2d`. A bare number is read as minutes. A resolution target shorter than the response target is refused. 4. **Count business hours only** decides whether the clock pauses outside working hours. Leave it off for a promise that must hold overnight. 5. **Use for every new ticket at this severity** makes it the default. If another default already holds that severity, the form names the one it will displace. One default per severity is enforced by the database as well. ## What it affects - **Business hours are the workspace's own** — the working week, the day start and end, and the timezone from [Settings](/docs/admin/settings), minus the full days on the holiday calendar. A four-hour target raised at 16:30 on the last working day is due at 11:30 on the next one, which is a Monday in Berlin and a Sunday in Riyadh. - **A ticket's deadlines are stamped once, when it is raised.** They are not recomputed on read. - **A missed target sets the breach flag on the ticket**, which is what starts the [escalation ladder](/docs/admin/escalation). - **Re-stamping a ticket's SLA clears the breach and resets its escalations.** - **The list shows a business-hours target in working days** rather than calendar hours, using this workspace's day length. 2400 calendar minutes is "1d 16h"; 2400 business minutes is five working days, and reading the first for the second is the largest gap between what an admin sets and what they think they set anywhere on this screen. ## On mobile This screen is web only. ## Limits and gotchas > [!WARNING] > Editing a policy does not move the deadlines on tickets already raised. That > is deliberate. Recomputed on read, a ticket raised under a four-hour promise > would silently acquire a two-hour one, retroactively breaching a batch of them > on a change nobody meant as a mass breach. - A workspace that has configured no working week at all falls back to Monday to Friday, 09:00–17:00, UTC. An SLA is not the screen on which to surface a bad settings row. - Removing a policy that has tickets measured against it says how many, and those tickets keep the deadlines already stamped on them. - The example deadline is rendered in the workspace's timezone, not the reader's, so a business-hours policy reads as a working morning wherever you are sitting. ## Related - [Escalation](/docs/admin/escalation) — who is told when one of these is missed. - [Customer status](/docs/admin/status) — what the customer sees while the clock runs. - [Settings](/docs/admin/settings) — the working week these targets are counted against. - [Support](/docs/workspace/support) — the tickets themselves. ## Related - [Escalation](https://projectri.com/docs/admin/escalation.md): Ladders that decide who is told when a support SLA is missed, how long each rung gets before it climbs, and on which channels. - [Customer status](https://projectri.com/docs/admin/status.md): What customers are told a ticket or a task is doing, mapped from the internal status your own team works in. - [Settings](https://projectri.com/docs/admin/settings.md): Branding, region, locale, the working week and storage policy — the tenant preferences that every other screen in Projectri reads. - [Support](https://projectri.com/docs/workspace/support.md): The internal ticket queue — raise, triage, reply to and resolve support tickets, with SLA state, escalations, work orders and a route into the knowledge base.