Assess

Routines

Create repeatable multi-step assessment workflows for an application.

Last updated August 2, 2026
On this page

Routines let you save an ordered assessment workflow and run it against an application later. Use them when your team wants the same sequence each time instead of rebuilding the launch plan manually.

Common examples include recon before a full assessment, source-code analysis before runtime testing, or a repeatable release-candidate workflow. The Routines page shows saved routines and recent runs together.

Routines page with saved routines and recent runs
The Routines page shows reusable routine definitions and recent routine runs.

#Provided templates

When provided routine templates are available, they appear in the Routines workflow. A template appears only when its assessment types are available for the selected application and organization. Choose Copy on a template to create a routine you can review and adjust, then save it before launching.

Before an application's first launch, recommended templates may appear under Recommended for your first assessment. To avoid duplication, they may not also appear in Provided routines, and they disappear after the first launch.

If no templates appear, create a routine manually or check Troubleshooting.

#Create a routine

Open Routines, then choose Create routine.

Add:

  • Routine name: use a short name that describes the workflow, such as Recon + source + full.
  • Description: optional context for your team.
  • Steps: the ordered assessment types Tahr should run.

Each step runs after the previous step completes. Move, remove, or add steps while building the routine.

Routines currently support up to 10 steps.

Create routine form with routine name, description, step selector, and input fallback options
The routine builder lets you name the routine, choose assessment steps, and decide whether a step may use saved recon or source-code output.

#Choose routine steps

Pick each assessment type based on the evidence later steps should use.

Good routine shapes:

  • Recon → Full assessment: use recon to map the target surface in a dedicated non-production environment before broader testing.
  • Source-code analysis → Full assessment: use repository findings and source context before runtime testing.
  • Recon → Source Code Analysis → Full Assessment: use external and code context before broad runtime testing.

Retest assessments are not supported inside routines yet. Run retests separately from the finding or assessment workflow.

Use Add step, choose the assessment type, and move it into order.

Add step button in the routine builder
Use Add step to add another assessment to the routine.

#Reusing recon and source outputs

Routines can pass useful output forward.

When a later step supports source-code or recon input, Tahr first uses output from the same routine run. If that input has not been produced, it can fall back to the application's latest saved result when enabled in the step settings.

Put recon before a runtime step when the runtime assessment should use fresh recon.

#Automatic reports

When Reports is enabled and configured, use the per-step toggle to generate a report automatically. Select the report type, format, and sections; available options depend on the organization and assessment. After a supported step completes, its generated report appears in Reports report history.

#Edit or archive a routine

Saved routines appear in the Saved routines list.

Use Edit to change the name, description, order, assessment types, input settings, or automatic report options.

Use Archive when a routine should no longer be used. Archiving removes it from the active routine list; it does not delete historical routine runs.

Saved routines list with Edit and Archive actions
Saved routines show their assessment sequence and actions for editing or archiving.

#Start a routine

Routine runs start from the assessment launch flow.

  1. Open Assessments.
  2. Choose the routine start mode when it is available.
  3. Select the application.
  4. Select the routine.
  5. Review blockers and warnings.
  6. Choose a reserved IP if the routine includes target-based testing, the selected application is behind a WAF, and Tahr requires one.
  7. Start the routine.

Tahr previews blockers before launch and checks again before each step. Fix blockers before starting.

New routine launches may be temporarily unavailable. Existing runs can continue, and scheduled occurrences may be skipped or advanced; check the visible schedule or run status before retrying.

Warnings can appear when a run may work but quality may be lower, such as authenticated testing without Sign-in automation.

#Reserved IP behavior

If the application is marked as behind a WAF, a routine containing any target-based assessment requires a reserved IP. A routine made entirely of repository-only steps, such as Threat Modeling, Source Code Analysis, or Source Code Diff Review, does not use a reserved IP. The selected reserved IP must be running and allowed for the application.

If no suitable reserved IP is available, reserve one in Administration before launching the routine. See Reserved IPs.

An active routine can prevent a reserved IP from being released. Wait for it to finish or choose another IP.

#Recent routine runs

Recent runs show:

  • Routine name.
  • Application name.
  • Overall run status.
  • Run timestamp.
  • Per-step status.
  • Step-level assessment type.
  • Any error attached to the run or step.

Routine statuses include:

  • Queued: the step is waiting for earlier work.
  • Running: the run or step is active.
  • Completed: the step finished successfully.
  • Failed: the step failed and later queued steps are skipped.
  • Skipped: the step did not run because an earlier step failed.
  • Cancelled: queued steps were cancelled by a user.

#Cancel queued steps

You can cancel queued steps for a running routine. This stops future steps from starting.

The currently running assessment is not automatically cancelled by the routine cancel action. If you need to stop the active assessment itself, handle that from the assessment run workflow.

#Routine design guidance

Keep routines focused. A routine should represent one repeatable testing workflow, not every possible assessment type.

Use separate routines when the intent is different:

  • One routine for release validation.
  • One routine for source-first review.
  • One routine for authorization-focused testing.
  • One routine for external recon.

Put context-producing steps first. Recon and source-code analysis are most useful when later steps can consume their results.

Avoid routines that depend on unstable test users, pending domain verification, or one-off manual setup. Fix the application setup first, then save the routine.

#Troubleshooting routines

If a routine cannot start, confirm that the application is ready, its assessment types are available, and its repository, API, authorization, authenticated-user, and reserved IP setup is complete. Also check that another assessment is not already active for the application. For a failed run, inspect the failed step first; later queued steps are skipped. See Troubleshooting for routine input issues.

Image preview