Skip to content

SLApulse User Guide

This site is the user handbook for SLApulse, operational SLA monitoring software for service teams. It helps teams turn source issue history into a live priority view and explain completed SLA results.

It explains how to set up a project, receive or import source data, operate the SLA ICU-style workflow, understand SLA state, review issues, and use reports.

For the product overview and practical guides on Jira SLA monitoring, breach prevention, service reviews, and SLA calculation, visit SLApulse resources.

How this guide is organized

The guide mirrors the main SLApulse app areas:

Section Read it when
Start You are new to SLApulse or setting up the first project.
Command Center You need the shared project-level entry point for readiness, live pressure, and next action.
Operations You need to read live SLA health, triage at-risk work, or keep critical SLAs under observation.
Analysis You need issue timelines, explanations, compliance reports, or exports.
Setup You administer projects, source connections, SLA rules, workspace settings, users, or billing.
Reference You need definitions or troubleshooting steps.

Start here

Use these guides in this order when you are setting up SLApulse for the first time:

  1. Getting started
  2. Projects and sources
  3. If you use Jira Cloud, set up Jira Cloud Automation.
  4. Map statuses and set SLA rules
  5. Validate your setup
  6. Use Command Center
  7. Run daily follow-up in Operations
  8. Review issue timelines and Reports

Read Concepts alongside the setup path when you want to understand why SLApulse treats a source status as a start, pause, or stop.

Main product areas

Area Use it for
Command Center See project-level readiness, live pressure, compliance, and the next action for each project.
Operations Use Health Monitor and Triage Board for live SLA work.
Analysis Use Issues and Reports for timelines, explanations, compliance, and exports.
Setup Use Projects, workspace Settings, Users, and Billing for admin-controlled configuration.

Roles

Your tenant role controls which areas are visible.

Role App access Typical focus
Member Command Center, Operations, Analysis, Profile Watch SLA health, triage work, inspect issues, and review reports.
Admin Everything a Member can use, plus Setup pages such as Projects, Settings, Users, and Billing Configure projects and sources, manage SLA rules, administer users, and keep billing active.

If a user cannot see Setup pages such as Projects, Settings, Users, or Billing, they are probably a Member. Ask a tenant Admin to make setup or billing changes.

Normal operating flow

Use the areas in this order:

  1. Configure projects, webhook delivery, source connections when you need source jobs, workflow mapping, users, and billing in the Setup area.
  2. Verify project readiness and next action in Command Center.
  3. Run daily SLA monitoring in Operations.
  4. Investigate individual issues and export evidence in Analysis.

Key concepts

SLApulse does not replace the source system where issues are managed. It listens to source issue history and maps status movement into SLA meaning:

  • Start begins SLA tracking.
  • Pause stops counting SLA time while an issue is waiting.
  • Stop Response records first response for duration-based policies.
  • Stop Resolution records resolution for duration-based policies.
  • Terminal marks the issue as finished.

Deadline-based policies use one deadline target instead of separate response and resolution phases.

For a fuller explanation, read Concepts.

ICU operating model

SLApulse uses an ICU-style operating model for current SLA work:

  1. Command Center admits projects into the operational picture and shows readiness.
  2. Operations reads vital signs, groups work by urgency, and keeps critical cases visible.
  3. Analysis provides the detailed chart and historical evidence.
  4. The Setup area controls the configuration that makes the ICU signal reliable.

The ICU model does not change SLA math. It changes how current risk is surfaced so teams can act before a breach becomes the only thing left to explain.

Example status mapping

Imagine a support team has Jira statuses like this:

New -> Selected for Development -> In Progress -> Waiting for Customer -> Ready for Test -> Done

A common first mapping could be:

Source status SLApulse meaning
New Start
In Progress Stop Response
Waiting for Customer Pause
Ready for Test Stop Resolution
Done Terminal

After live collection or import, the team should inspect a few real issues before trusting reports. If an issue starts with Done and no earlier Start was observed, it should be excluded. That is expected: SLApulse only counts issues where it saw a reliable SLA start.

When to use troubleshooting

Use Common user problems and Troubleshooting when an issue is missing from reports, appears excluded, imports show unexpected progress, or the lifecycle timeline does not match your expectation.