SLAs

An SLA (service-level agreement) sets a target time-to-respond and time-to-resolve on customer conversations and tickets. Hydra tracks each open conversation and ticket against its target, surfaces a countdown chip in the inbox / tickets list, and notifies the assignee (or all admins, when unassigned) when a target is missed.

The setting lives at Settings → SLA Policies.

The two axes

Every SLA has two clocks running in parallel:

• First response — how long an agent has to send the first non-internal reply after the customer's first message lands.
• Resolution — how long the conversation or ticket can stay open before it must be marked Resolved (or, for tickets, Closed).

Either axis can be left blank. A policy with both axes blank is allowed (it disables tracking without forcing you to delete the row), but most teams set both.

Where targets are defined

You can set:

• A tenant-default conversation policy — applied to any conversation whose channel doesn't have its own override.
• A tenant-default ticket policy — same idea, for tickets.
• Per-channel overrides — a separate policy per (channel, entity_type) pair, e.g. one for your VIP-support channel that is tighter than the default.

The lookup is "channel-specific first, tenant default second, otherwise no SLA tracked" — so a conversation in a channel with no specific policy still inherits the tenant default.

Tickets without a parent conversation (e.g. created directly from + New Ticket) always use the tenant-default ticket policy because there is no channel to scope by.

Pausing outside business hours

Each policy has a Pause timer outside business hours toggle. When on:

• The clock only counts business-hours minutes — a Friday-evening conversation doesn't burn through its target overnight.
• Hydra reads the tenant's Business Hours config (Settings → Business Hours) to decide what counts as open. Holidays count as closed.
• The due-at instant is recomputed whenever you change the SLA policy or the business-hours config.

When off, the clock is plain wall-clock — now + target_minutes regardless of when humans are at the keyboard.

If you have no business hours configured at all, "pause outside hours" has no effect — Hydra treats the tenant as always open.

Where targets are surfaced

• Inbox — each conversation row shows a small SLA chip with the time remaining (or -Xh OVERDUE after a breach). Green = comfortable, amber = under one hour remaining, red = breached. The chip surfaces the racing axis: first-response while it's unmet, then resolution once first-response lands.
• Tickets list — same chip pattern, on every open / in-progress / waiting ticket.
• Settled rows hide the chip — once a conversation is Resolved or a ticket is Closed, the chip disappears even if the SLA was breached.

Breach notifications

When an SLA target slips, Hydra fires one notification per breach axis:

• Recipient — the assignee, if there is one. If unassigned, all teammates with Admin or Owner role on the tenant.
• Channels — the in-app bell drawer and (if email is enabled in the recipient's prefs) an email from noreply@hydra-help.com linking back to the conversation or ticket.
• Idempotency — each axis is stamped after notification so you only get paged once per breach. If a row breaches first-response, gets notified, and then later breaches resolution, you get a second notification — they're independent axes.

You control delivery channels per event type at Settings → Notifications. The new event type is SLA breaches:

• In-app bell toggle — when off, breach notifications still land in the database (audit trail preserved) but the bell drawer doesn't show them.
• Email toggle — when off, no email is sent for breach events; the in-app bell still surfaces them.

How recompute works

Hydra recomputes due-at instants in two places, never on a cron:

• When you save an SLA policy — open conversations / tickets in the affected scope have their due-ats recomputed in place. Already-stamped met_at values and breach notifications are preserved (those are historical facts).
• When you save business hours — open conversations / tickets whose policy uses "pause outside hours" get recomputed so the new schedule reflects in their due-at.

Both recompute paths run inside the same request that saved the change, so the recompute is complete before the page refreshes.

Permissions

• Any teammate can view the policies on Settings → SLA Policies.
• Only admins and owners can change them.

Changes are recorded in Team → Audit log as "Changed SLA policies" with a count of how many policies are saved and whether a tenant-default exists for each entity type.

Frequently asked questions

Why doesn't the chip show on a conversation that has the SLA configured? The chip hides on settled rows (Resolved / Closed) and on rows with no state row at all. State rows are created lazily — if a conversation predates the policy, it will only get a state row when you save / re-save the policy, which triggers a recompute across all open rows in scope.

Do internal notes count as a first response? No. Only non-internal replies the customer can see stamp first_response_met_at.

What about the bot's first reply — does that count? The bot's auto-replies are inserted as messages (role assistant), not as conversation_replies from an admin. The first-response axis is about a human responding, so the bot's reply does NOT stamp first_response_met_at.

Can I change the breach notification recipients? Not in v1. The rule is fixed: assignee if assigned, otherwise admins and owners. If you need finer-grained routing, that's a candidate for a later wave.

Is there a webhook or Slack delivery for breaches? Not in v1. The two delivery channels are bell + email. Slack / webhook delivery would land alongside the notifications system, not specifically tied to SLA.

What happens to in-flight conversations when I delete a policy? The state rows have a policy_id FK with ON DELETE SET NULL. Their due-at values are preserved as a historical record but no further recompute will land on them. New conversations after the delete fall back to the tenant default (or get no SLA if no default exists).