Concepts¶
FastSLA helps teams turn issue history into contract-ready SLA follow-up.
Most teams already manage work in a source system such as Jira. That source system knows which issues exist and which statuses they moved through. FastSLA adds a separate interpretation layer: it decides which status changes matter for SLA measurement, calculates targets, and shows whether the work met the agreed service level.
The problem FastSLA solves¶
SLA follow-up is difficult when the source workflow is richer than the contract.
A source project may have many statuses:
New -> Triaged -> In Progress -> Waiting for Customer -> Ready for Test -> Done
The contract usually cares about fewer moments:
- when the issue entered SLA scope
- when the first response happened
- whether time should pause while waiting
- when resolution happened
- whether the issue is finished
FastSLA maps detailed source history into those SLA meanings, then calculates compliance consistently across issues and report windows.
Source history versus SLA meaning¶
FastSLA does not assume every source status has SLA meaning.
Some statuses change the SLA state:
| Source movement | Possible SLA meaning |
|---|---|
| New customer request | Start |
| Work begins or first answer sent | Stop Response |
| Waiting for customer | Pause |
| Ready for test or solved | Stop Resolution |
| Closed | Terminal |
Other statuses may be useful history without changing SLA:
| Source movement | SLA effect |
|---|---|
| Internal board column change | No effect |
| Team ownership change | No effect |
| Technical refinement status | No effect |
No-effect statuses can still appear in issue history and on the lifecycle timeline, but they should not change compliance.
Reliable start is required¶
FastSLA only counts an issue when it has observed a reliable Start.
This protects reports from counting old issues that were already closed, paused, or partially complete before FastSLA saw the beginning of the SLA period.
Example:
| Observed first status | Result |
|---|---|
New mapped as Start |
Issue can count in SLA. |
Closed mapped as Terminal |
Issue is excluded unless a later real Start is observed. |
Waiting for Customer mapped as Pause |
Issue is excluded until a Start is observed. |
Excluded issues are not treated as failed. They are left out because FastSLA does not have enough reliable history to measure them fairly.
Two SLA measurement styles¶
FastSLA supports two common ways to measure SLA.
Response and resolution¶
This style measures two phases:
| Phase | Meaning |
|---|---|
| Response | How long it took to first respond or start handling the issue. |
| Resolution | How long it took to resolve the issue. |
Use this when the contract has separate response and resolution targets.
Deadline mode¶
Deadline mode measures one overall target from Start to a deadline.
Use this when the contract says that an issue must be completed before a single target time, rather than splitting response and resolution.
Business hours versus continuous time¶
SLA time can be measured continuously or within business hours.
| Clock mode | Use it when |
|---|---|
| Continuous | The SLA runs 24/7. |
| Business hours | Only configured working time should count. |
Business-hours policies use the project's working calendar. Warning notifications for business-hours SLAs are also scheduled and sent inside open business time.
Operational view versus contract view¶
FastSLA separates current operations from historical compliance.
| Page | Main question |
|---|---|
| Overview | What needs attention right now? |
| Issues | What is the current state of each issue? |
| Reports | Did completed measurements meet the contract in this period? |
This means an issue can appear in Reports but not Overview. For example, a terminal breached issue may still count in historical reporting, but it no longer needs current operational attention.
Mental model¶
Use this model when reviewing FastSLA data:
- Source data says what happened.
- Status mapping says which events matter.
- Project filters say which issues are eligible.
- SLA rules calculate targets and outcomes.
- Overview shows current work.
- Reports show contract follow-up.
When numbers look unexpected, work backward through those layers.