v8 coverage reports for Playwright

Currently we only support collecting coverage reports from instrumented code (via istanbuljs), but Playwright can collect v8 coverage reports directly from supporting browsers.

Automated Jira Issue Creation

It would be very useful to have currents automatically create jira issues based on run/ test conditional logic. My use case specifically would be: Tests that fail and that have one or more team tags “[team1, team2]” automatically create a jira issue in the associated team project in jira per a configured mapping. We can than distribute the work amongst teams

Test failure root cause classification and triage

Description: When viewing a specific test failure, there’s no way to classify the root cause from a development/triage perspective. This makes it hard to: Quickly identify which failures need immediate attention vs. known issues Measure test suite health accurately Prioritize engineering effort appropriately Proposed Solution: A manual classification/tagging system for test failures that allows users to categorize the root cause when viewing individual test failures. Suggested categories: Product Bug — Actual defect in the application Flaky Test — Intermittent failure due to test instability Environment Issue — Infrastructure, network, or test environment problems Test Bug — Issue with the test code itself Known Issue — Linked to an existing tracked bug (e.g., JIRA) Under Investigation — Not yet triaged Note: This is different from Currents’ existing automatic error classification (Category, Action, Target), which identifies what technically caused the error from the test’s perspective. This feature would add manual triage classification to indicate which part of the development cycle is responsible for the failure. Benefits: Enable error identification and triage directly from the test failure view Quickly determine what action to take on each test error Better visibility into failure root causes More accurate test suite health metrics Improved prioritization of engineering work Use Case: When viewing a specific test failure, users should be able to classify it to indicate whether it’s a product bug requiring immediate attention, a known flaky test, an environment issue, or something under investigation.

Artifact Support (Screenshots, Videos, Logs) in Currents Generic Reporter Context

Our CI pipeline runs end-to-end tests (Detox + Jest) for a React Native application. Due to current limitations with the @currents/jest reporter in a CommonJS environment, we’re using a workaround that converts JUnit XML reports into Currents reports for upload. This flow works functionally but lacks one key capability: attaching artifacts (screenshots, videos, logs) to the test results. These files are essential for debugging failures and verifying UI regressions in mobile E2E testing. Problem Currently: The JUnit → Currents conversion format doesn’t support artifacts. The Jest reporter also doesn’t include any mechanism for uploading files, as it uses the same generic Currents upload command. As confirmed by Currents support (Miguel, 22 Oct 2025), “right now it is not supported,” and this applies to both JUnit and Jest reporters. This limitation means that for frameworks like Detox or Cypress, where screenshot and video evidence are a standard part of test artifacts, Currents reports lose critical debugging data. Proposed Solution Add artifact attachment support to the generic Currents reporter and the data format reference, allowing uploads of associated files such as: Test-level screenshots and videos (e.g., recorded per test case) Test-level Log files or trace dumps Possibly, arbitrary attachments (e.g., JSON results or CLI outputs) Ideally, this would work both: When uploading via the CLI (currents upload ...), referencing artifact file paths in metadata. And when using reporter integrations (@currents/jest), automatically attaching files from known locations (like artifactsDir) based on testName or other matching identification. Impact Adding artifact support would: Greatly improve debugging and analysis of E2E test failures. Bring Currents in line with other reporting platforms (like Allure or TestRail integrations). Enable teams to migrate fully to Currents even when not using supported reporters directly (e.g., when working through converted reports). Reduce friction for users in monorepos, CI pipelines, or multi-environment setups where direct ESM usage isn’t feasible. Additional Notes Miguel mentioned the team “has plans to bump the generic reporter to support more things,” but no ETA is available.

Show Spot instances preemptions

The customer needs to have a way to see the preemptions (notified interruptions) of Spot instances. Why do you need this feature? need is a strong word, but you we offer the option to rebalance tests when VMs are preempted, its nice to know that it happened and to have stats on when it happened. If we know when / how many times it occurs, it could help us to fine tune our VM settings to reduce the occurrence of preemptions (choose different regions, machine sizes etc.). Also if a test run times out, which if test rebalancing did correctly happen, it is good to know that Spot VMs played no part in that, and an indicator would help us to know that the VM had not been preempted/rebalanced. Why would it help your organization? we have the ability to track the cost impact of using Spot VMs (via GCP), but not each occurrence

Add ability to change the color scheme: e.g. I want to see passed test run as green

Project-level permissions

Allow controlling project-level permissions and roles, for example a user can be and admin in one project but blocked from accessing another project and have a different role in another project

Native CI Orchestration: Trigger and Re-run Tests Directly from the Currents Dashboard

The Problem: The "Context-Switching" Friction Currently, our testing workflow is fragmented across two platforms. To initiate or re-run a test suite, we must navigate to GitHub Actions; to analyze the results, we must then switch over to Currents.dev. This back-and-forth creates unnecessary friction, slows down the debugging cycle, and forces developers to manage two different interfaces for a single task. The Proposal: A Unified Execution & Observation Hub We would like to propose the ability to trigger and manage test runs directly from within the Currents.dev UI. Instead of Currents being a passive destination for results, it would become an active orchestration hub. This functionality would allow teams to: Launch New Runs: Trigger specific GitHub Action workflows (via repository dispatch or similar integration) directly from the Currents dashboard. Smart Re-runs: Re-execute failed tests or entire flakes with a single click inside the Currents run view, rather than hunting for the specific job in CI. Centralized Control: View real-time logs and execution progress without ever leaving the Currents ecosystem. Why this is a Game-Changer: Velocity: Dramatically reduces the "Mean Time to Repair" (MTTR) by allowing developers to re-run failed tests the moment they identify them in the dashboard. Simplified DX (Developer Experience): Provides a "Single Pane of Glass" for the entire testing lifecycle—from execution to post-mortem analysis. Competitive Alignment: Similar orchestration capabilities are highly valued in other dashboard environments (like Cypress Cloud), and bringing this to Currents would solidify its position as the premier choice for scalable test management. By bridging the gap between CI execution and Currents reporting, you would be providing a seamless, world-class workflow that saves time for every engineer on the team.

Allow hard limit for test recording

Hello, I’m a new user of Currents and our team was hoping to set a hard limit for test recording each billing cycle. It seems like this isn’t currently an option and there is no easy way to check current usage using the CLI tools prior to recording tests, so it requires a manual step to disable things when we reach our desired monthly limit. It would be great to have the capability of setting a hard limit for test recording (for example — 10k/month) in the UI and have test 10,001+ not automatically record and push our billing over the limit. Would something like this be possible? Thanks!

Show skip rate metric for spec files

With the introduction of actions, it is important to know what is the skip rate to be able remove/add actions based on the metrics.

Email notifications with run results

Send an email similar to Slack and Teams reports as an email notification with passed, failed tests and a link to the currents run in it.

Allow excluding tests by tags in Tests Explorer

Problem description: The current tag filtering system in Tests Explorer does not support proper exclusion when tests have multiple tags. A test can belong to several tags (for example, core and nightly). Because of this, it is impossible to fully exclude tests that contain a specific tag. When attempting to exclude a tag such as core, tests that also have another tag (like nightly) still appear in the results. Similarly, excluding nightly does not work if every test includes at least one additional tag. As a result, users cannot reliably hide tests associated with certain tags, which limits the usefulness of tag-based filtering in environments where tests frequently have multiple tags. Proposed solution: Introduce a tag exclusion mechanism in Tests Explorer that allows users to filter out any tests containing one or more specified tags.

Send an alert if a test exceeds a flakiness rate threshold

Whenever a test exceed a certain threshold of flakiness (or other metric), send an alert / notification to an email address or to an integration. Example scenario If a test exceeds 20% flakiness rate based on 14-day recordings, from a particular branch, then we send an alert to test owner or a designated email.

Support NodeJS Test Runner

Vitest support

Code Coverage for Playwright

Flat Test List view

Have a dashboard view within the run that shows a list of all the tests and that allows applying filters. This is very helpful as it is not needed to go inside each spec file to check each test.

Jira Integration

Enable integration with Jira to open tickets related to test failures. The feature includes: - secure integration with Jira space - listing projects - creating new tickets in Jira with a reference to Currents tests - linking test failure to an existing Jira ticket P.S. Can be implemented today with webhooks on a Run level.

More granular roles for the Currents dashboard

Currently, the ability to create and modify Currents Actions (such as skipping or quarantining tests) is limited only to users with the Admin role. However, this Admin role also grants access to sensitive areas like team management and billing details. It would be ideal to have a role that can create & manage Currents Actions but cannot modify any organisation/team or billing-related details, so some kind of Test Manager role. Such separation would help us delegate test management responsibilities more effectively while maintaining appropriate access controls for administrative functions.

Find Annotated Tests

https://docs.currents.dev/guides/playwright-annotations I conditionally add an annotation during the test run. I want the ability to find all the tests where this annotation occurred. “Test Explorer” does not allow me to filter for the annotation to find where / when this annotation occurred.

Integration with Linear

Enable integration with Linear to open tickets related to test failures. P.S. Can be implemented today with webhooks on a Run level.

Support of webdriver.io

GitHub Commit Status: Single check for all groups

Having a commit status check for each project run can be too noisy. Some customers are only interested in knowing whether any of the groups failed. Desired: A single check "Current Tests" for all 3 groups. Notes: This might be a more common scenario with users that have one project for their main test suites, and additional projects for "setup"/"teardown". Having the groups' execution details outlined in the PR comment is useful and shouldn't be changed.