Skip to main content
Once issues are reported to a client, the question becomes how fast they get fixed. Remediation velocity answers it with four numbers, on the project dashboard (above Issues by risk) and across every client on the Command Center. It appears when Synapse is turned on, since the SLA and retest flow it measures live there.

The four numbers

Mean time to fix

The average number of days from the day a finding was logged to the day its fix was confirmed, with a breakdown by severity. The number counts up when the band opens.

Fixed within SLA

The share of fixed issues closed on or before their SLA deadline, shown as a ring: green from 80%, amber from 50%, red below.

Past SLA, still open

Reported issues already over their deadline. Red when there are any; click to open them.

Trend

The last 90 days of fixes against the 90 before: faster, slower or steady, with both averages.

Where the dates come from

  • Fixed date. The day a retest confirmed the fix, when a retest marked the issue fixed. That is the real, verified fix date. An issue marked fixed without a retest uses the day its record last changed.
  • Deadline. The issue’s own due date when one is set, otherwise the day it was logged plus the SLA days for its severity. The defaults are 7 days for critical, 30 for high, 90 for medium and 120 for low, and you can change them globally or per project under Synapse. See The workflow.
  • Past SLA only counts issues that have been reported to the client, because that is when the client’s clock starts. An issue still in review is not overdue.
False positives and informational notes are left out of every number.
A client who reopens a fix they disputed drops out of the fixed count until the issue is fixed again, so velocity never counts a fix that did not hold.

Before there is anything to measure

A project with no fixed issues yet shows one line instead of empty gauges: velocity appears once issues are remediated and a retest confirms the fix.