Your Playwright report is in GitHub Actions. The screenshot is in a Slack thread from last Tuesday. The coverage data is in an S3 bucket that two people have access to. When a test fails, the first ten minutes aren’t spent debugging. They’re spent finding the evidence.
That is the storage problem, and it is separate from the question of what test artifacts are. If you want the definitions and the file types first, read What Are Test Artifacts in Software Testing?. This page is about where the files go once your CI has produced them, and how anyone on the team gets to them without a zip download.

Which Test Artifacts Are Worth Storing
Five kinds of file are worth keeping after a run, because each answers a question you will ask later:
- Test Reports - HTML, JSON, or XML summaries of test results (Playwright, Jest, Vitest, pytest, JUnit)
- Screenshots & Videos - Visual evidence of test failures, especially for E2E tests
- Log Files - Console output, stack traces, and debugging information
- Coverage Reports - Code coverage data showing which lines were tested
- Performance Metrics - Timing data, memory usage, and resource consumption
All five are cheap to generate and easy to lose. Producing them is not the hard part. Finding the right one three weeks later is.
The CI Artifact Expiration Problem
Most CI/CD platforms (GitHub Actions, GitLab CI, CircleCI) automatically delete test artifacts after a retention period - typically 30-90 days. This creates real problems:
- Debugging old failures - When a bug resurfaces, the original test artifacts are gone
- Compliance audits - Regulated industries need to retain test evidence for years, not months
- Onboarding engineers - New team members can’t see historical context for test behavior
- Flaky test analysis - Understanding intermittent failures requires data across many runs
Even worse, accessing artifacts while they exist is painful. You have to navigate to the CI provider, find the right workflow run, download a zip file, and extract it locally.
How Gaffer Solves Test Artifact Management
Gaffer provides searchable storage for your test artifacts with configurable retention and instant team access:
Automatic Upload from CI
Add one step to your CI pipeline and Gaffer captures your test artifacts automatically:
- name: Upload to Gaffer uses: gaffer-sh/gaffer-uploader@v2 with: gaffer_upload_token: ${{ secrets.GAFFER_PROJECT_TOKEN }} report_path: ./test-resultsInstant Team Sharing
Every test run gets a URL in the Gaffer dashboard. Share it in Slack, add it to a bug ticket, or bookmark it for later. No downloads, no zip files.
For external collaborators, you can generate public share links with configurable expiration. They view the results in their browser without needing a Gaffer account.
Slack Notifications
Get notified in Slack when tests fail, with a direct link to the full report. Filter notifications by branch so you only hear about failures that matter.
Historical Analytics
Track test health over time with pass rate trends, flaky test detection, and historical analytics.
Supported Test Frameworks
Gaffer works with the test artifacts you already generate:
| Framework | Report Types |
|---|---|
| Playwright | HTML reports, traces, screenshots |
| Jest | JSON output, jest-html-reporter |
| Vitest | HTML reports, JSON output |
| pytest | pytest-html, JUnit XML |
| Any framework | JUnit XML, CTRF JSON |
Test Artifacts Best Practices
- Generate structured reports - HTML or JSON reports are more useful than plain text logs
- Include screenshots on failure - Visual evidence makes debugging faster
- Store artifacts with longer retention - Don’t rely on short CI retention policies
- Make artifacts accessible - If your team can’t find artifacts easily, they won’t use them
- Track trends over time - Individual test runs matter less than patterns across runs
Get Started
Gaffer’s free tier includes 500 MB of artifact storage with 7-day retention. Paid plans offer extended retention (up to 90 days) and up to 50 GB of storage.