Configure Allure Report 3

Allure Report 3 uses a single configuration file to manage all your report settings. You can create this file in either dynamic (JavaScript) or static (JSON/YAML) format. Dynamic configs support executable code, imports, and conditional logic, while static configs provide a simpler format with fixed values.

You can load configuration values from environment variables and override them via CLI command options, giving you flexibility in how you manage settings across different environments and workflows.

Advanced Allure 3 features are implemented as a system of plugins. You can configure all plugins in the same configuration file.

What This Document Covers

• Configuration file structure and syntax
• All primary configuration options
• Adding plugins and configuring multiple reports types
• Advanced features like history tracking and known issues
• CLI commands and overrides

1. Configuration File Basics

File Name and Location

Allure CLI looks for configuration files in the current working directory, in the following order (first file discovered gets parsed for configuration parameters):

• allurerc.js
• allurerc.mjs
• allurerc.cjs
• allurerc.json
• allurerc.yaml
• allurerc.yml

File Format and Syntax

Allure 3 supports both dynamic configs (.mjs, .cjs, .js) and static configs (.json, .yml, .yaml).

Static configs have limited functionality (no imports, no reading from environment variables, no executable code) but work with a global install of Allure Report 3.

Dynamic config files are written in JavaScript. They require Allure 3 to be locally installed in your project and you can use the following in them:

• Environment variables
• Conditional logic
• Computed values
• Imported utilities

Dynamic and Static Configuration File Examples

allurerc.mjs

import { defineConfig } from "allure";

export default defineConfig({
  name: "Allure Report",
  output: "./allure-report",
  historyPath: "./history.jsonl",
  qualityGate: {
    rules: [
      {
        maxFailures: 5,
        fastFail: true,
      },
    ],
  },
  plugins: {
    awesome: {
      options: {
        reportName: "HelloWorld",
        singleFile: false,
        reportLanguage: "en",
        open: false,
        charts: chartLayout,
        publish: true,
      },
    },
    allure2: {
      options: {
        reportName: "HelloWorld",
        singleFile: false,
        reportLanguage: "en",
      },
    },
    classic: {
      options: {
        reportName: "HelloWorld",
        singleFile: false,
        reportLanguage: "en",
      },
    },
    dashboard: {
      options: {
        singleFile: false,
        reportName: "HelloWorld-Dashboard",
        reportLanguage: "en",
        layout: defaultChartsConfig,
      },
    },
    csv: {
      options: {
        fileName: "allure-report.csv",
      },
    },
    log: {
      options: {
        groupBy: "none",
      },
    },
  },
  variables: {
    env_variable: "unknown",
  },
  environments: {
    foo: {
      variables: {
        env_variable: "foo",
        env_specific_variable: "foo",
      },
      matcher: ({ labels }) => labels.some(({ name, value }) => name === "env" && value === "foo"),
    },
    bar: {
      variables: {
        env_variable: "bar",
        env_specific_variable: "bar",
      },
      matcher: ({ labels }) => labels.some(({ name, value }) => name === "env" && value === "bar"),
    },
  },
});

allurerc.json

{
  "name": "Allure Report",
  "output": "./allure-report",
  "historyPath": "./history.jsonl",
  "qualityGate": {
    "rules": [
      {
        "maxFailures": 5,
        "fastFail": true
      }
    ]
  },
  "plugins": {
    "awesome": {
      "options": {
        "reportName": "HelloWorld",
        "singleFile": false,
        "reportLanguage": "en",
        "open": false,
        "publish": true
      }
    },
    "allure2": {
      "options": {
        "reportName": "HelloWorld",
        "singleFile": false,
        "reportLanguage": "en"
      }
    },
    "classic": {
      "options": {
        "reportName": "HelloWorld",
        "singleFile": false,
        "reportLanguage": "en"
      }
    },
    "dashboard": {
      "options": {
        "singleFile": false,
        "reportName": "HelloWorld-Dashboard",
        "reportLanguage": "en"
      }
    },
    "csv": {
      "options": {
        "fileName": "allure-report.csv"
      }
    },
    "log": {
      "options": {
        "groupBy": "none"
      }
    }
  },
  "variables": {
    "env_variable": "unknown"
  }
}

allurerc.yaml

name: Allure Report
output: ./allure-report
historyPath: ./history.jsonl
qualityGate:
  rules:
    - maxFailures: 5
      fastFail: true
plugins:
  allure2:
    options:
      reportName: HelloWorld
      singleFile: false
      reportLanguage: en
  classic:
    options:
      reportName: HelloWorld
      singleFile: false
      reportLanguage: en
  awesome:
    options:
      reportName: HelloWorld
      singleFile: false
      reportLanguage: en
      open: false
      publish: true
  dashboard:
    options:
      singleFile: false
      reportName: HelloWorld-Dashboard
      reportLanguage: en
  csv:
    options:
      fileName: allure-report.csv
  log:
    options:
      groupBy: none
variables:
  env_variable: unknown

Dynamic Config File Capabilities and Prerequisites

For Node.js Projects

Add Allure as a development dependency to your project:

cd your-project
npm install -D allure

Then, wrap the configuration object with the defineConfig function:

import { defineConfig } from "allure";

export default defineConfig({
  name: "My Allure Report",
  // ... configuration
});

For Other Types of Projects

You can use a global installation of Allure Report and just export the configuration object directly:

export default {
  name: "My Allure Report",
  // ... configuration
};

This way, however, you won't get type hints.

You can get around that limitation by initializing a dummy Node.js project and installing Allure to it:

npm init --yes
npm install -D allure

Then, wrap the configuration object in the defineConfig function, just as you would for any Node.js project (see the section above).

Reading Environment Variables

Since dynamic config files are executable JavaScript, you can use:

import { env } from "node:process";

export default {
  name: env.REPORT_NAME || "Default Report",
  output: env.CI ? "./ci-reports" : "./local-reports",
};

Importing Code

When using dymanic files you can offload some executable logic to other JavaScript files and then import it to your config from them.

You can also import code form other Node.js modules, including Allure 3 plugins.

Default Top-Level Values Reference

Option	Default Value
name	"Allure Report"
output	"./allure-report"
open	false
port	undefined (random)
historyPath	undefined
appendHistory	true
historyLimit	undefined (unlimited)
categories	{ rules: [{ name: "Product errors", matchers: { statuses: ["failed"] } }, { name: "Test errors", matchers: { statuses: ["broken"] } }] }
variables	{}
environments	{}
environment	undefined
allowedEnvironments	undefined
defaultLabels	{}
hideLabels	undefined
knownIssuesPath	"./allure/known.json"
plugins	{ awesome: { options: {} } }
qualityGate	{}
dump	undefined
globalAttachments	undefined

2. Basic Configuration Options

name

• Type: string
• Default: "Allure Report"
• Description: Display name for the report

{
  name: "My Test Suite Report";
}

output

• Type: string
• Default: "./allure-report"
• Description: Directory where the report will be generated

{
  output: "./reports/allure";
}

open

• Type: boolean
• Default: false
• Description: After generation completes, starts a local static file server and opens the report in the default browser. Use together with port to control the server port.

{
  open: true;
}

port

• Type: string
• Default: undefined (random available port)
• Description: Port for the local server started when open: true. If omitted, a random available port is chosen.

{
  port: "3000";
}

hideLabels

• Type: (string | RegExp)[]
• Default: undefined
• Description: Hides labels from the report UI by label name. Does not filter tests out — only affects what is displayed. Labels whose name starts with _ are always hidden regardless of this setting.

{
  hideLabels: ["package", "thread", /^allure_id/];
}

dump

• Type: string
• Default: undefined
• Description: When set, archives the processed test result state to a .zip file at the given path (.zip is appended automatically) instead of running report plugins. The archive can later be restored using the --dump flag on the generate CLI command.

{
  dump: "./snapshots/run-2025-10-20";
  // produces ./snapshots/run-2025-10-20.zip
}

Documentation: See Multistage Builds for complete documentation.

globalAttachments

• Type: string[]
• Default: undefined
• Description: Glob patterns (relative to the working directory) for files to attach to the report globally, independent of any test result. Only files inside the working directory are included; paths resolving outside it are silently skipped.

{
  globalAttachments: ["./logs/*.log", "./screenshots/global/**/*.png"];
}

Documentation: See Global Errors and Attachments for complete documentation.

3. History Options

historyPath

• Type: string
• Default: undefined
• Description: Path to the history file that tracks test results across multiple runs
• Format: JSONL (JSON Lines) - each line contains data from one complete test run
• Used for:
  • Trend charts showing test behavior over time
  • Flaky test detection
  • Historical comparisons

{
  historyPath: "./test-history/allure-history.jsonl";
}

appendHistory

• Type: boolean
• Default: true
• Description: Controls history accumulation behavior

{
  appendHistory: true;
}

historyLimit

• Type: number
• Default: undefined (unlimited)
• Description: Caps the number of past runs retained in the history file. When the file exceeds this count, the oldest entries are dropped. Has no effect if historyPath is not set.

{
  historyLimit: 20;
}

File Structure: See History File document for details.

4. Categories

Define custom categories to group and classify failed and broken tests by status, error message, labels, and other criteria.

• Type: { rules: CategoryRule[] }
• Default: Two built-in categories — Product errors (failed) and Test errors (broken)
• Purpose: Create a "Categories" tab in reports that groups test results by error type. All test results are matched against custom rules first, in the order defined; unmatched failed/broken tests fall back to the default categories.

Structure

{
  categories: {
    rules: [
      {
        name: "Category title",           // Required
        id: "category-id",                // Optional, stable identifier that allows to change name
        matchers: { ... } | (data) => boolean | [...],  // Required, either object matcher or function matcher
        groupBy: ["severity", "owner"],   // Optional, determines organization levels
        groupByMessage: true,             // Optional, default: true
        groupEnvironments: true,          // Optional
        expand: false,                    // Optional, default: false
        hide: false,                      // Optional, default: false
      }
    ]
  }
}

You may also set categories: false to disable categories entirely (neither default categories nor custom rules will be applied).

matchers

matchers is mandatory and has to be one of the following:

• Object matcher - a plain object with any combination of:

  • statuses: TestStatus[] - matches against test status, e.g. ["failed", "broken"].
  • flaky: boolean - determines whether the category should include flaky tests. Requires history to work.
  • labels: { [labelName]: string | RegExp } - matches against labels, as a regular expression. String input is converted into a RegExp object, so any regex metacharacters included in the string (like ., *, or ^) will affect how the match behaves, e.g. { owner: /^alice/ } will match all results where the owner label starts with alice.
  • message: (sub)string | RegExp - matches against the error message as a regular expression. Same as labels, any regex metacharacters in a provided string will affect the match.
  • trace: (sub)string | RegExp - matches against the stack trace as a regular expression. Same as labels, any regex metacharacters in a provided string will affect the match.
  • transitions: TestStatusTransition[] - matches against transitions, e.g. ["new", "regressed"]. Requires history to work.
  • environments: string[] - matches against environments.

  Tests fitting all of these conditions will be included (AND logic applies here).

• Function matcher — (data) => boolean, where data contains status, labels, message, trace, flaky, duration, transition, environment.

  Function matcher requires dynamic config to work, and just like with object matchers, you have to enable history to match against flaky and transition, and set environments to match against environment.

  When using function matchers, you can additionally filter by duration (e.g. (data) => data.duration > 5000 ), implement complex logic gates across multiple conditions and use arbitrary JavaScript expressions to fine-tune your categories.

• Array — any mix of the above; the test matches if any matcher in the array matches (OR logic applies).

groupBy

groupBy is optional, controls the nesting hierarchy inside the category tree. Each element is either a built-in string selector or a custom label object:

• Built-ins: "flaky", "owner", "severity", "transition", "status", "environment", "layer"
• Custom labels: { label: "myCustomLabel" }

Example: groupBy: ["severity", { label: "feature" }] creates two levels of grouping — first by severity, then by feature — before showing individual test results.

Example

Categories via object matchers

import { defineConfig } from "allure";

export default defineConfig({
  name: "Allure Report 3",
  output: "./allure-report",
  historyPath: "./history.jsonl", //required for flaky and status transitions detection
  categories: {
    rules: [
      {
        name: "Critical regressions by layer",
        id: "critical-regressions-by-layer",
        // this section determines what's included into the category
        matchers: {
          statuses: ["failed", "broken"],
          flaky: false,
          labels: { severity: "critical" },
          message: /expected|API/, // accepts regular expressions
          trace: /AssertionError|timeout|unexpected/, // accepts regular expressions
          transitions: ["regressed", "malfunctioned"],
          environments: ["staging", "production"],
        },

        // this section determines how the category is presented
        groupBy: ["layer", "owner", "status"],
        groupByMessage: true,
        groupEnvironments: true,
        expand: true,
        hide: false,
      },
    ],
  },
});

Categories via function matchers

import { defineConfig } from "allure";

export default defineConfig({
  name: "Allure Report 3",
  output: "./allure-report",
  historyPath: "./history.jsonl", //required for flaky and status transitions detection
  categories: {
    rules: [
      {
        name: "Critical regressions by layer",
        id: "critical-regressions-by-layer",
        // this section determines what's included into the category
        matchers: (data) =>
          (data.status === "failed" || data.status === "broken") &&
          !data.flaky &&
          data.labels.some((l) => l.name === "severity" && l.value === "critical") &&
          /expected|API/.test(data.message ?? "") &&
          /AssertionError|timeout|unexpected/.test(data.trace ?? "") &&
          (data.transition === "regressed" || data.transition === "malfunctioned") &&
          (data.environment === "staging" || data.environment === "production"),
        // this section determines how the category is presented
        groupBy: ["layer", "owner", "status"],
        groupByMessage: true,
        groupEnvironments: true,
        expand: true,
        hide: false,
      },
    ],
  },
});

Documentation: See Categories Guide for complete documentation.

5. Variables and Labels

variables

Display custom key-value metadata at the top of the report.

• Type: Record<string, string>
• Default: {}
• Where shown: Top of report in awesome plugin
• Purpose: Display build/run metadata

Example

{
  variables: {
    "App Version": "2.5.1",
    "Test Suite": "Regression v1.2",
    "Launch Date": "2025-10-20",
    "Build Number": "#1234",
    "Environment": "Staging"
  }
}

defaultLabels

Apply default labels to tests.

• Type: Record<string, string | string[]>
• Default: {}
• Behavior: Non-overriding - only applies if test doesn't have that label
• Purpose: Provide fallback values for missing labels

Example

{
  defaultLabels: {
    "severity": "normal",
    "owner": "unassigned",
    "layer": "unknown",
    "tags": ["needs-review"]
  }
}

How It Works

• Test with severity: "critical" → keeps "critical" (not overridden)
• Test without severity → gets "normal" from defaults
• Test without tags → gets ["needs-review"]
• Test with tags: ["smoke"] → keeps ["smoke"]

Label Values

Single value:

"severity": "critical"

Multiple values (array):

"tags": ["smoke", "regression", "api"]

6. Environments

Group and categorize test results by environment with custom matching logic.

• Type: Record<string, EnvironmentDescriptor>
• Default: {}
• Purpose: Create an "Environments" menu in reports and split test result tree into environment-based groups, which you can switch between using that menu.

Structure

{
  environments: {
    "environment-id": {                    // Key = ID: letters, digits, underscores, hyphens only
      name?: string,                       // Optional display name shown in the report; defaults to the ID
      matcher: ({ labels }) => boolean,    // Required
      variables?: Record<string, string>   // Optional
    }
  }
}

Matcher Function

Receives test labels and returns true if the test belongs to this environment. Requires dynamic config to work.

Payload structure:

{
  labels: [
    { name: "os", value: "Windows" },
    { name: "browser", value: "Chrome" },
    // ... more labels
  ];
}

Note: these labels should be set in the tests as there are no default values for environment labels.

Example

OS-based Environments

{
  environments: {
    windows: {
      matcher: ({ labels }) =>
        labels.find(({ name, value }) => name === "os" && value === "Windows"),
      variables: {
        "OS": "Windows 11",
        "Architecture": "x64"
      }
    },
    macos: {
      matcher: ({ labels }) =>
        labels.find(({ name, value }) => name === "os" && value === "macOS"),
      variables: {
        "OS": "macOS Sonoma",
        "Architecture": "arm64"
      }
    },
    linux: {
      matcher: ({ labels }) =>
        labels.find(({ name, value }) => name === "os" && value === "Linux"),
      variables: {
        "OS": "Ubuntu 22.04",
        "Architecture": "x64"
      }
    }
  }
}

Deployment Environments

{
  environments: {
    staging: {
      matcher: ({ labels }) =>
        labels.find(l => l.name === "env" && l.value === "staging"),
      variables: {
        "Server": "staging.example.com",
        "Database": "staging-db"
      }
    },
    production: {
      matcher: ({ labels }) =>
        labels.find(l => l.name === "env" && l.value === "production"),
      variables: {
        "Server": "api.example.com",
        "Database": "prod-db-primary"
      }
    }
  }
}

Environment Variables

Optional environment-specific variables override or extend global variables when viewing that environment.

Merge behavior:

1. Global variables shown in all views
2. Environment-specific variables override/add to globals when that environment is selected

Use Cases

• Group tests by OS (Windows/macOS/Linux)
• Group by browser (Chrome/Firefox/Safari)
• Group by deployment environment (staging/production)
• Group by any custom label-based criteria

environment

Note: This is a top-level option.

• Type: string
• Default: undefined
• Description: Force-assigns a single environment ID to all test results in this run, bypassing the matcher logic in environments. Use this when you don't need dynamic label-based matching and already know which environment you're running against. Takes precedence over any matched environment.

{
  environment: "staging";
}

allowedEnvironments

Note: This is a top-level option.

• Type: string[]
• Default: undefined
• Description: Restricts which environment IDs are considered valid. When set, any environment ID — from the environments map, the environment override, or test result data — that is not in this list will cause a validation error at startup. Use this to enforce a fixed set of known environments and catch misconfigurations early.

{
  allowedEnvironments: ["staging", "production", "windows", "macos"];
}

Documentation: See Environments Guide for complete documentation.

7. Known Issues Management

Track known test failures and link them to bug tracker tickets.

knownIssuesPath

• Type: string
• Default: "./allure/known.json"
• Description: Path to JSON file containing known test failures

{
  knownIssuesPath: "./config/known.json";
}

File Structure

File: JSON array of known issue objects

[
  {
    "historyId": "a3f5e9b2c1d4f8a7b6e5c4d3a2f1e0b9",
    "issues": [
      {
        "name": "JIRA-1234",
        "url": "https://jira.example.com/browse/JIRA-1234"
      }
    ],
    "comment": "Known flaky test due to database connection issues",
    "error": {
      "message": "Connection timeout"
    }
  }
]

Fields

historyId (required)

• Type: string
• Description: The test's history ID (internal identifier unique to each test)
• Format: MD5 hash of test metadata (name, path, parameters)
• How to get: From raw test result files

issues (optional)

• Type: Array of link objects
• Description: Links to bug tracker tickets

{
  "name": "JIRA-1234",
  "url": "https://jira.example.com/browse/JIRA-1234"
}

comment (optional)

• Type: string
• Description: Human-readable explanation of the known issue

error (optional)

• Type: Error object
• Description: Expected error pattern for this known issue

{
  "message": "Connection timeout after 5000ms",
  "trace": "..."
}

Creating Known Issues File

Automated (Recommended)

Use the CLI command to auto-generate from failed tests:

allure known-issue ./allure-results

What it does:

1. Finds all failed/broken tests
2. Extracts their historyId
3. Extracts any "issue" type links from test metadata
4. Creates known-issues.json with standard comment

Manual

1. Find the historyId from raw test result files
2. Create or edit known.json
3. Add entry with desired fields

How It Works

1. Test runs and has a historyId
2. Allure checks if this historyId exists in known issues
3. If match found:
   • Test marked as "known failure"
   • Issue links displayed
   • Comment shown
   • May affect Quality Gate evaluation

Use Cases

• Track known flaky tests
• Link failures to bug tracker
• Provide context to team members
• Separate "new failures" from "known issues"
• Document expected failures

8. Plugin Configuration

Plugin System Overview

Allure 3 uses a plugin-based architecture. Each plugin generates a specific type of report or provides additional functionality.

Available Official Plugins:

• awesome - Modern UI (recommended)
• classic - Classic-style UI
• allure2 - Allure 2-style UI
• dashboard - Dashboard view with charts
• log - Console log output
• csv - CSV export
• slack - Slack integration
• testplan - Test plan generation
• jira - Jira integration

You can find the official plugins code in the Allure 3 repository.

Basic Plugin Configuration

To enable a plugin in your project, install the plugin package:

npm add @allurereport/plugin-name

And add it to the plugins section of the config:

{
  plugins: {
    "name": {
      options: {
        // plugin-specific options
      }
    }
  }
}

Plugin Configuration Properties

import (optional)

Custom module path for the plugin

{
  plugins: {
    "my-custom-id": {
      import: "@allurereport/plugin-awesome",
      options: {}
    }
  }
}

Use case: Running multiple instances of the same plugin with different configurations

enabled (optional)

Enable or disable the plugin

• Type: boolean
• Default: true

{
  plugins: {
    awesome: {
      enabled: false,  // Disable this plugin
      options: {}
    }
  }
}

options (optional)

Plugin-specific configuration object

• Type: Record<string, any>
• Default: {}

{
  plugins: {
    awesome: {
      options: {
        singleFile: true,
        reportLanguage: "en"
      }
    }
  }
}

Multiple Reports

You can generate multiple reports by configuring multiple plugins:

{
  plugins: {
    "awesome-framework": {
      import: "@allurereport/plugin-awesome",
      options: {
        reportName: "Framework View",
        groupBy: ["framework", "language"]
      }
    },
    "awesome-package": {
      import: "@allurereport/plugin-awesome",
      options: {
        reportName: "Package View",
        groupBy: ["package", "suite"]
      }
    },
    dashboard: {
      options: {
        reportName: "Dashboard"
      }
    }
  }
}

Default Plugin

If no plugins are specified, Allure uses the awesome plugin by default:

// These are equivalent:
export default { name: "Report" }

export default {
  name: "Report",
  plugins: {
    awesome: { options: {} }
  }
}

9. Plugin Options

Awesome Plugin

Recommended modern UI for Allure reports.

Common Options

reportName (string)

• Overrides the top-level name for this report

singleFile (boolean, default: false)

• Generate report as a single standalone HTML file
• true: Single HTML file
• false: Multiple files

reportLanguage (default: "en")

• Sets the UI language

groupBy (string[])

• Defines test result hierarchy organization
• Array of label names

Common patterns:

// BDD-style hierarchy
groupBy: ["epic", "feature", "story"];

// Suite-based hierarchy
groupBy: ["parentSuite", "suite", "subSuite"];

// Package-based hierarchy
groupBy: ["package", "class", "method"];

// Module-based
groupBy: ["module", "parentSuite", "suite", "subSuite"];

// Custom hierarchy
groupBy: ["framework", "language", "package"];

filter (function) Requires dynamic config

• Determines which test results are included in the report.
• Receives a test result object; return a truthy value to include, falsy to exclude

Common patterns:

// Include only tests with a specific label
filter: ({ labels }) =>
  labels.find(({ name, value }) => name === "framework" && value === "playwright");

// Exclude tests with a specific label
filter: ({ labels }) => !labels.find(({ name, value }) => name === "language" && value === "java");

charts (default: all charts included)

• Built-in charts configuration: charts configured here will be included in the Awesome report itself. Do not confuse with Dashboard, which is a separate charts-only report type.
• For details on what the charts illustrate, please refer to the full Charts documentation.
• To populate most charts properly, history should be enabled.
• If charts is omitted, all available chart types are included with their default options, which you can review below:

Full charts configuration example with all default options

import { defineConfig } from "allure";

// Charts configuration with all chart types and all options set to default values
const allChartsDefaultValues = [
  {
    type: "currentStatus",
    title: "Current status",
    statuses: ["passed", "failed", "broken", "skipped", "unknown"], //included statuses
    metric: "passed", // status used to calculate the central percentage value
  },

  {
    type: "testResultSeverities",
    title: "Test results by severities",
    levels: ["blocker", "critical", "normal", "minor", "trivial"],  //included severities
    statuses: ["passed", "failed", "broken", "skipped", "unknown"], //included statuses
    includeUnset: true, //whether to show the “No severity“ section
  },

  {
    type: "statusDynamics",
    title: "Status dynamics",
    limit: 10, // number of shown runs, including the latest
    statuses: ["passed", "failed", "broken", "skipped", "unknown"], //included statuses
  },

  {
    type: "statusTransitions",
    title: "Status transitions",
    limit: 10, // number of shown runs, including the latest
  },

  {
    type: "testBaseGrowthDynamics",
    title: "Test base growth dynamics",
    statuses: ["passed", "failed", "broken", "skipped", "unknown"], //included statuses
    limit: 10, // number of shown runs, including the latest
  },  

  {
    type: "coverageDiff",
    title: "Coverage diff map",
  },

  {
    type: "successRateDistribution",
    title: "Success rate distribution",
  },

  {
    type: "problemsDistribution",
    title: "Problems distribution by environment",
    by: "environment", //can only be grouped by environments
  },

  {
    type: "stabilityDistribution",
    title: "Stability distribution by features",
    threshold: 90, // acceptable stability level in %
    skipStatuses: ["skipped", "unknown"], //skipped test statuses
    groupBy: "feature", //by what label to group the tests together
  },

  {
    type: "stabilityDistribution",
    title: "Stability distribution by epics",
    threshold: 90, // acceptable stability level in %
    skipStatuses: ["skipped", "unknown"], //skipped test statuses
    groupBy: "epic", //by what label to group the tests together
  },

  {
    type: "stabilityDistribution",
    title: "Stability distribution by stories",
    threshold: 90,  // acceptable stability level in %
    skipStatuses: ["skipped", "unknown"], //skipped test statuses
    groupBy: "story", //by what label to group the tests together
  },

  {
    type: "durations",
    title: "Durations histogram",
    groupBy: "none", //whether to group the tests by layer (other labels not supported)
  },

  {
    type: "durations",
    title: "Durations by layer histogram",
    groupBy: "layer", //whether to group the tests by layer (other labels not supported)
  },

  {
    type: "durationDynamics",
    title: "Durations dynamics",
    limit: 10, // number of shown runs, including the latest
  },

  {
    type: "statusAgePyramid",
    title: "Status age pyramid",
    limit: 10, // number of shown runs, including the latest
  },

  {
    type: "testingPyramid",
    title: "Testing pyramid",
    layers: ["unit", "integration", "e2e"], //layers of the pyramid, bottom to top
  },
];

export default defineConfig({
  name: "Allure Report",
  output: "./allure-report",
  // history file configuration is required to populate most charts
  historyPath: "./history.jsonl",

  plugins: {
    awesome: {
      options: {
        reportName: "Allure Report",
        singleFile: false,
        reportLanguage: "en",
        // charts configuration used within the Awesome report
        charts: allChartsDefaultValues, 
      },
    },

    dashboard: {
      options: {
        reportName: "Dashboard",
        singleFile: false,
        reportLanguage: "en",
        // charts configuration used in a Dashboard report
        layout: allChartsDefaultValues, 
      },
    },
  },
});

Example Configuration

{
  plugins: {
    awesome: {
      options: {
        singleFile: false,
        reportLanguage: "en",
        reportName: "My Awesome Report",
        groupBy: ["epic", "feature", "story"],
        filter: ({ labels }) => labels.find(({ name, value }) => name === "framework" && value === "playwright")
      }
    }
  }
}

Complete Options Reference

For all available options including experimental features, see:

• AwesomePluginOptions source code

Dashboard Plugin

Dashboard view with charts and visualizations.

Common Options

reportName (string)

• Dashboard title

singleFile (boolean, default: false)

• Generate as single file

reportLanguage (default: "en")

• UI language

layout (array of widget configurations)

• Dashboard report charts configuration
• For details on what different charts illustrate, please refer to the full Charts documentation.
• To populate most charts properly, history should be enabled.
• If layout is omitted, all available chart types are included with their default options, which you can review below:

filter (function) Requires dynamic config

• Determines which test results are included in the dashboard. Receives a test result object; return a truthy value to include, falsy to exclude.

Example Configuration

Full charts configuration example with all default options

import { defineConfig } from "allure";

// Charts configuration with all chart types and all options set to default values
const allChartsDefaultValues = [
  {
    type: "currentStatus",
    title: "Current status",
    statuses: ["passed", "failed", "broken", "skipped", "unknown"], //included statuses
    metric: "passed", // status used to calculate the central percentage value
  },

  {
    type: "testResultSeverities",
    title: "Test results by severities",
    levels: ["blocker", "critical", "normal", "minor", "trivial"],  //included severities
    statuses: ["passed", "failed", "broken", "skipped", "unknown"], //included statuses
    includeUnset: true, //whether to show the “No severity“ section
  },

  {
    type: "statusDynamics",
    title: "Status dynamics",
    limit: 10, // number of shown runs, including the latest
    statuses: ["passed", "failed", "broken", "skipped", "unknown"], //included statuses
  },

  {
    type: "statusTransitions",
    title: "Status transitions",
    limit: 10, // number of shown runs, including the latest
  },

  {
    type: "testBaseGrowthDynamics",
    title: "Test base growth dynamics",
    statuses: ["passed", "failed", "broken", "skipped", "unknown"], //included statuses
    limit: 10, // number of shown runs, including the latest
  },  

  {
    type: "coverageDiff",
    title: "Coverage diff map",
  },

  {
    type: "successRateDistribution",
    title: "Success rate distribution",
  },

  {
    type: "problemsDistribution",
    title: "Problems distribution by environment",
    by: "environment", //can only be grouped by environments
  },

  {
    type: "stabilityDistribution",
    title: "Stability distribution by features",
    threshold: 90, // acceptable stability level in %
    skipStatuses: ["skipped", "unknown"], //skipped test statuses
    groupBy: "feature", //by what label to group the tests together
  },

  {
    type: "stabilityDistribution",
    title: "Stability distribution by epics",
    threshold: 90, // acceptable stability level in %
    skipStatuses: ["skipped", "unknown"], //skipped test statuses
    groupBy: "epic", //by what label to group the tests together
  },

  {
    type: "stabilityDistribution",
    title: "Stability distribution by stories",
    threshold: 90,  // acceptable stability level in %
    skipStatuses: ["skipped", "unknown"], //skipped test statuses
    groupBy: "story", //by what label to group the tests together
  },

  {
    type: "durations",
    title: "Durations histogram",
    groupBy: "none", //whether to group the tests by layer (other labels not supported)
  },

  {
    type: "durations",
    title: "Durations by layer histogram",
    groupBy: "layer", //whether to group the tests by layer (other labels not supported)
  },

  {
    type: "durationDynamics",
    title: "Durations dynamics",
    limit: 10, // number of shown runs, including the latest
  },

  {
    type: "statusAgePyramid",
    title: "Status age pyramid",
    limit: 10, // number of shown runs, including the latest
  },

  {
    type: "testingPyramid",
    title: "Testing pyramid",
    layers: ["unit", "integration", "e2e"], //layers of the pyramid, bottom to top
  },
];

export default defineConfig({
  name: "Allure Report",
  output: "./allure-report",
  // history file configuration is required to populate most charts
  historyPath: "./history.jsonl",

  plugins: {
    awesome: {
      options: {
        reportName: "Allure Report",
        singleFile: false,
        reportLanguage: "en",
        // charts configuration used within the Awesome report
        charts: allChartsDefaultValues, 
      },
    },

    dashboard: {
      options: {
        reportName: "Dashboard",
        singleFile: false,
        reportLanguage: "en",
        // charts configuration used in a Dashboard report
        layout: allChartsDefaultValues, 
      },
    },
  },
});

Complete Options Reference

For all available options, see:

• DashboardPluginOptions source code

Note: Dashboard generates a standalone report separate from other plugins.

Allure2 Plugin

Allure 2-style UI

Common Options

reportName (string)

• Overrides the top-level name for this report

singleFile (boolean, default: false)

• Generate report as a single standalone HTML file

reportLanguage (default: "en")

• Sets the UI language

createdAt (number)

• Report creation timestamp in milliseconds since epoch. Defaults to the current time if not set.

Complete Options Reference

For all available options, see:

• Allure2PluginOptions source code

Classic Plugin

Classic UI.

Common Options

reportName (string) reportLanguage (default: "en") singleFile (boolean)

Complete Options Reference

For all available options, see:

• ClassicPluginOptions source code

CSV Plugin

Exports test results as a CSV file.

Options

fileName (string, default: "allure-report.csv")

• Output file name for the CSV export

separator (string, default: ",")

• Field separator character

disableHeaders (boolean, default: false)

• When true, omits the header row from the output

fields (array) Requires dynamic config

• Custom column definitions. Each entry has a header string and an accessor — either a key of the test result object or a function (result) => string.

sort (function) Requires dynamic config

• Sort function applied to test results before writing. Receives two test result objects; follows standard Array.sort comparison conventions.

filter (function) Requires dynamic config

• Determines which test results are included. Receives a test result object; return a truthy value to include, falsy to exclude.

Example Configuration

{
  plugins: {
    csv: {
      options: {
        fileName: "results.csv",
        separator: ";",
        filter: ({ status }) => status === "failed",
        fields: [
          { header: "Name", accessor: "name" },
          { header: "Status", accessor: "status" },
          { header: "Duration (ms)", accessor: ({ duration }) => String(duration ?? "") }
        ]
      }
    }
  }
}

Complete Options Reference

For all available options, see:

• CsvPluginOptions source code

Log Plugin

Prints test results to the console.

Options

groupBy ("suites" | "features" | "packages" | "none", default: "none")

• Groups console output by the specified hierarchy before listing test results

allSteps (boolean, default: false)

• Show all steps in the output. By default only steps from failed tests are shown.

withTrace (boolean, default: false)

• Include stack traces for failed tests

filter (function) Requires dynamic config

• Determines which test results are printed. Receives a test result object; return a truthy value to include, falsy to exclude.

Example Configuration

{
  plugins: {
    log: {
      options: {
        groupBy: "suites",
        allSteps: false,
        withTrace: true,
        filter: ({ status }) => status === "failed" || status === "broken"
      }
    }
  }
}

Slack Plugin

Posts a test results summary to a Slack channel.

Options

token (string)

• Slack Bot User OAuth Token. Can also be provided via the ALLURE_SLACK_TOKEN environment variable.

channel (string)

• Slack channel ID to post to. Can also be provided via the ALLURE_SLACK_CHANNEL environment variable.

The plugin posts a message containing a breakdown of test counts by status (failed, broken, passed, skipped, unknown) and a list of failed test names.

Example Configuration

import { env } from "node:process";

export default {
  plugins: {
    slack: {
      options: {
        token: env.ALLURE_SLACK_TOKEN,
        channel: env.ALLURE_SLACK_CHANNEL,
      },
    },
  },
};

Complete Options Reference

For all available options, see:

• SlackPlugin source code

TestPlan Plugin

Generates a testplan.json file for re-running a subset of tests.

The file lists the tests that matched the filter — by default, all unsuccessful tests from the run. It can be passed to a supported test framework to re-execute only those tests.

Options

fileName (string, default: "testplan.json")

• Output file name

filter (function) Requires dynamic config

• Determines which test results are included in the test plan. Defaults to all unsuccessful (failed, broken, or otherwise non-passing) tests.

Example Configuration

{
  plugins: {
    testplan: {
      options: {
        fileName: "rerun.json",
        filter: ({ status }) => status === "failed"
      }
    }
  }
}

Complete Options Reference

For all available options, see:

• TestPlanPlugin source code

TestOps Plugin

Uploads test results to Allure TestOps.

Options

endpoint (string, required)

• Allure TestOps instance URL

accessToken (string, required)

• API access token for authentication

projectId (string, required)

• Target project ID in Allure TestOps

launchName (string, required)

• Display name for the launch created in TestOps

launchTags (string[], required)

• Tags to attach to the launch

autocloseLaunch (boolean, default: false)

• Automatically close the launch in TestOps after upload completes

limit (number, default: unlimited)

• Maximum number of test results to upload per batch

filter (function) Requires dynamic config

• Determines which test results are uploaded. Receives a test result object; return a truthy value to include, falsy to exclude.

Example Configuration

import { env } from "node:process";

export default {
  plugins: {
    testops: {
      import: "@allurereport/plugin-testops",
      options: {
        endpoint: env.TESTOPS_URL,
        accessToken: env.TESTOPS_TOKEN,
        projectId: env.TESTOPS_PROJECT_ID,
        launchName: "Regression Suite",
        launchTags: ["regression", "nightly"],
        autocloseLaunch: true,
      },
    },
  },
};

Complete Options Reference

For all available options, see:

• TestOpsPluginOptions source code

10. Quality Gate

Controls the process exit code based on test result criteria, allowing test runs to pass or fail based on custom rules.

{
  qualityGate: {
    rules: [
      {
        maxFailures: 5,
      },
    ];
  }
}

Documentation: See Quality Gate Guide for complete documentation.

Note: This is a complex feature with its own dedicated documentation.

CLI Configuration Overrides

Config options can be overridden from the command line:

allure generate \
  --config ./allurerc.mjs \
  --output ./custom-output \
  --name "Overridden Name"

Overridable options:

• --name / --report-name
• --output / -o
• --known-issues
• Plugin-specific options (varies by command)

Plugin-Specific Commands

Generate reports with specific plugins directly:

Awesome Report

allure awesome [options] <directory>

Options:

• --single-file
• --logo
• --theme
• --report-language, --lang
• --group-by, -g

Dashboard

allure dashboard [options] <directory>

Classic Report

allure classic [options] <directory>

CSV Export

allure csv [options] <directory>

Log Output

allure log [options] <directory>

Utility Commands

Known Issues

allure known-issue [--output,-o] <directory>

Generates known issues file from failed tests.

History

allure history [--history-path,-h] [--report-name,--name] <directory>

Generates history to specified folder.

Test Plan

allure testplan [--output,-o] <directory>

Generates testplan.json.

Help

Get detailed help for any command:

allure <command> --help

---

Appendix: Type Definitions Reference

For reference, here are the main TypeScript interfaces that define the configuration structure:

Config Interface

interface Config {
  name?: string;
  output?: string;
  historyPath?: string;
  knownIssuesPath?: string;
  defaultLabels?: DefaultLabelsConfig;
  environments?: EnvironmentsConfig;
  variables?: ReportVariables;
  plugins?: Record<string, PluginDescriptor>;
  appendHistory?: boolean;
  qualityGate?: QualityGateConfig;
  allureService?: {
    accessToken?: string;
  };
}

Supporting Types

type DefaultLabelsConfig = Record<string, string | string[]>;

type ReportVariables = Record<string, string>;

type EnvironmentDescriptor = {
  name?: string;
  variables?: ReportVariables;
  matcher: (payload: { labels: TestLabel[] }) => boolean;
};

type EnvironmentsConfig = Record<string, EnvironmentDescriptor>;

interface PluginDescriptor {
  import?: string;
  enabled?: boolean;
  options?: Record<string, any>;
}

interface KnownTestFailure {
  historyId: string;
  issues?: TestLink[];
  comment?: string;
  error?: TestError;
}

Additional Resources

• Allure 3 GitHub Repository
• Charts and Visual analytics documentation
• Environments Feature
• Quality Gate Feature