Test an SLA timer against the priority that sets it

The flow under test

Three values have to agree with each other, and the arithmetic between them is the actual subject of the test.

• The priority - Urgent, which is what selects the target.
• The target - 60 minutes, the first reply commitment for that priority.
• The elapsed time - 55 minutes open.
• The remaining margin - 5 minutes, which is the target less the elapsed time.

Asserting all four is what makes the countdown checkable. A badge reading five minutes remaining is only correct if the target is sixty and fifty five have elapsed, and a timer counting against the wrong target looks entirely normal.

The test file

The ticket is identified by number and subject, so the SLA assertions are demonstrably about the urgent ticket rather than whichever one happened to open.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/zendesk-clone-app/agent?reset=true
max_steps: 40
tags: [zendesk, support, sla]
---

# Zendisk 30.5: SLA breach indicator

Catalog objective: verify the SLA timer displays on a priority ticket.
Key assertion: the timer is visible with the correct target.

## Open the urgent ticket
Click "Open" on ticket 4412 and verify the page title reads "#4412 · Payment taken twice for order #1188".

## Verify the SLA card is present
Verify a "First reply SLA" card is shown with "Priority" of "Urgent".

## Verify the target matches the priority
Verify "Target" reads "60 minutes", which is the first-reply target for Urgent.

## Verify the elapsed time and the state
Verify "Open for" reads "55 minutes" and the SLA badge reads "5 min remaining", since 55 of the 60 minute target have elapsed.

The file states why the target is sixty minutes, tying it to the priority, so the expectation and its justification stay together.

Step by step coverage

A ticket, a card, a target and the maths.

Tying the target to the priority in the assertion is what catches an SLA policy change that was applied to the table but not to the tickets reading from it.

Running it

kane-cli testmd run tests/zendesk/sla-breach-indicator_test.md

Add a breached ticket, since the state after the target has passed is the one the business actually cares about and the one least likely to be designed.

SLA policies change by contract rather than by release. Deriving a suite from requirements covers keeping targets anchored, and running flows in CI covers catching drift.