Retests and monitoring conversion

Use retests and monitoring conversion to verify applied fixes, decide resolved, recurring or inconclusive states, and move eligible checks into monitoring.

Business owners, developers and agencies

Feature availability

Product, package, provider and deployment boundaries for this page.

Available from
Current documentation
Deployment modes
cloud

Before retest conversion

Use this page after a fix task has customer-applied evidence or an approved connected change. Retests verify whether the original finding changed, and monitoring conversion decides whether a recurring check should continue after the task is resolved or still failing. Do not mark an issue fixed from a note alone. The retest outcome must explain whether the issue passed, failed, stayed inconclusive or needs recurring monitoring.

Run retest and decide next state

Follow the path `Customer-applied evidence → Retest → Retest outcome → Plus → Scheduled scans`.

  1. Open /reports/{report} and choose the fix task or remediation workflow with applied evidence. Result: expected fix, before evidence, customer_applied_status and retest controls are visible.
  2. Confirm customer-applied evidence or an approved connected change exists. Result: WebRiskOps knows what changed before it queues verification.
  3. Run the retest from the task or report workflow. Result: retest_status moves to pending, queued, passed, failed or inconclusive.
  4. Read Retest outcomes before marking the issue resolved. Result: passed confirms observed fix, failed returns to remediation, and Inconclusive retest keeps the issue under review.
  5. Open /billing and confirm the Plus is active before conversion. Result: recurring checks are not offered without plan readiness.
  6. Open /projects/{project}/monitoring and enable scheduled monitoring only for recurring or eligible checks. Result: monitoring_status and next_scan_at show the follow-up cadence.

Retest and monitoring states

Use the retest state to choose the next automated action.

  • Passed retest means observed evidence no longer shows the issue, so the task can move toward resolved status.
  • Failed retest means the issue still appears and the task should return to remediation or ticket-only handoff.
  • Inconclusive retest means evidence is missing, blocked or not comparable; use the related Inconclusive evidence page before closing work.
  • Monitoring ready means billing, baseline and scan cadence are ready for scheduled follow-up checks.
  • Monitoring active means `/projects/{project}/monitoring` shows the cadence, next run and issue-change state.

Blocked or unavailable states

Do not convert a task to monitoring when verification is blocked.

  • No applied evidence means return to customer-applied evidence before requesting verification.
  • Retest unavailable means wait for the task or plan state that allows verification.
  • Monitoring plan required means open /billing or the related Monitoring plans page and choose an available Plus.
  • No baseline means run or wait for the first scheduled scan before comparing recurring issues.
  • Inconclusive retest means do not mark fixed until missing evidence is resolved.

Continue to monitoring

Continue with the related Retest outcomes page to interpret verification states, then use the related Scheduled scans and Issue change states pages after monitoring is active.

Related documentation

Was this page helpful?

Feedback goes into the product documentation review queue.