A test run can reach a storage limit while the evidence from earlier runs remains available. The immediate problem is the next screenshot, recording, or diagnostic attachment that cannot be added. Deleting the largest files may restore capacity, but it can also remove the original failure or release evidence that another reviewer still needs.
Managing Xray Cloud test evidence storage therefore requires two decisions: which storage allowance applies to the files, and which evidence the organization is authorized to remove. Make those decisions before selecting attachments for deletion.
Files displayed inside Jira do not necessarily share the same storage location. Xray's current Cloud documentation distinguishes ordinary Jira issue attachments from attachments managed by the app. Its storage contribution table assigns issue-level attachments and files embedded in issue descriptions to Atlassian storage. It assigns attachments on Test-definition steps and evidence attached to Test Runs, including run-step evidence, to Xray storage.
The attachment context also changes its meaning. An image attached to a reusable Test step can explain how to perform that step. A screenshot attached as evidence to a Test Run records an observation from a particular execution. Keep those records distinct when assessing what can be removed: deleting a reusable reference and deleting proof of a failed execution have different consequences.
Do not assume that every item stored by Xray contributes to its attachment usage. The overview separately marks textual logs on test results, comments, actual results, and Xray backups as stored by Xray but not contributing to that usage. An attached log file remains a different artifact from text recorded in a result field.
Historical attachments need special attention. Xray says attachments created before June 20, 2020 remain in Jira issues and are not migrated to Xray Storage. That date describes a storage transition, not a retention deadline. Identify the actual attachment location rather than assuming that cleaning one store will free space in the other.
The native Jira issue-attachment REST documentation is a separate interface boundary. It describes Jira attachment settings and metadata, not a universal way to enumerate or export every Xray evidence object. An inventory based only on native Jira attachments must not be presented as a complete Xray evidence inventory.
Xray's current Storage overview lists the following allowances. The scope is the Xray instance, not a separate allowance for every Jira project.
Edition | Documented Storage per Xray Instance |
|---|---|
Xray Standard | 100 GB |
Xray Advanced | 250 GB |
Xray Enterprise | Unlimited |
The official documentation is inconsistent. The Storage overview lists 250 GB for Advanced, while the separate Global Settings: Storage guide still describes a Cloud account as limited to 100 GB and Enterprise as unlimited. Both the freshly retrieved advertised Markdown and the rendered official settings page retain that broader 100 GB statement. Do not apply it as a universal Cloud limit. Ask the authorized administrator to verify the licensed edition and the limit displayed for the specific instance; resolve a discrepancy with Xray before relying on an entitlement.
The overview also says that separate Jira instances with Xray installed have their own storage allocation. Do not treat unused capacity in another instance as available headroom for the instance approaching its limit.
According to the overview, exceeding the limit prevents adding new attachments to Test Steps or Test Runs. Its assurance that subscriptions will not be canceled and existing data will not be removed is conditional on acceptable use. That statement is not an organizational retention policy or a guarantee that every other upload, import, or integration behaves identically.
If required evidence cannot safely be removed, review the supported capacity options with the administrator rather than deleting protected history to keep uploads moving.
The documented Cloud route is Jira Settings, then Apps, then Xray, then Storage. Xray requires permission to access the Jira Global settings page. Confirm the controls available in your tenant with an authorized administrator; membership in a testing project alone does not establish access to this management screen.
Before refreshing usage, secure any previously generated downloads or reports that you still need. The settings documentation says generated ZIP and CSV files remain available for seven days or until storage is refreshed. Its advertised Markdown also warns that a usage refresh removes previously generated files and that refresh is time-gated. Treat generated download availability as temporary, not as your evidence archive.
The rendered settings guide describes an initially empty attachment list that must be populated with Refresh Storage Usage. It also warns that the operation can take time. A blank list before that process completes should not be interpreted as proof that the instance contains no evidence. Follow the tenant's displayed refresh availability rather than assuming an immediate or fixed refresh interval.
Once the inventory is available, the documented controls support:
Filters affect the status bar and file-type usage breakdown. A project-filtered view therefore describes that selection, not necessarily the entire instance's remaining capacity. Record the filter context with any inventory used for a decision.
Date modified is also not the same as execution date, release acceptance date, or the start of a required retention period. Use it to find candidates, then establish their actual testing context before making a retention decision.
A usable archive needs the evidence itself and enough context to explain it. Xray documents different operations for downloading attachment content and exporting attachment details. Neither should be substituted for the other.
The settings guide describes selecting attachments and choosing Download through Actions to generate a ZIP. Export to CSV instead produces attachment details using the filters and ordering applied to the page. The documented CSV fields are Project Key, File Name, Author, Date Modified, and Size; the export dialog also asks for a delimiter.
A CSV containing filenames and sizes is not a copy of the screenshots or recordings. A ZIP containing files does not, by itself, establish their relationship to a particular failed run, build, or release decision. Obtain the needed content and metadata before approving removal.
Download generated files before the seven-day window ends and before another storage refresh removes their availability. Check that the downloaded archive opens and that the intended files are present and readable. Store required material in an approved location with access suitable for its sensitivity and intended reviewers. A temporary download link is not evidence that the organization has custody of a verified copy.
The following manifest is a proposed local practice, not a set of native Xray fields or an automatic export feature. For each retained artifact, record the source project and entity, the relevant test and execution reference, the step where applicable, the build and environment, and the release or investigation it supports. Add the archive location, responsible owner, and retention decision. A checksum can help identify the exact copied file, but it does not prove that the file is sufficient evidence.
Use Open entity where available to inspect the attachment's source. The documentation says it identifies the Xray issue type where the attachment is located. Do not assume the CSV automatically supplies a complete test-to-run-to-defect mapping. Verify that context separately and mark missing information as unresolved rather than filling it from a filename guess.
Retention decisions belong to the organization's approved process. The recommendations here are human review controls, not claims that Xray provides automatic legal holds, approval routing, or retention enforcement.
Keep the original failure and its later retest distinguishable. A passing retest may support closure of a defect, but the earlier evidence can still explain what failed and why the correction was accepted. The related guide to verifying bug fixes in Jira describes preserving the original failure alongside a separate, traceable retest.
Before treating an attachment as disposable, ask whether it supports an unresolved defect, a reopened issue, an active investigation, a release sign-off, or another required review. Where retention obligations or holds apply, obtain the responsible owner's decision through the approved process. A file that is old, large, or associated with a passing result is not automatically eligible for deletion.
Define retention by evidence purpose and applicable obligations rather than inventing one universal duration. A short-lived rehearsal recording and an artifact required to explain an accepted release can need different treatment. If the decision depends on an inaccessible owner or uncertain obligation, exclude the attachment from the cleanup selection until that question is resolved.
Xray documents single-attachment deletion and bulk deletion, each with a confirmation modal. The bulk controls include project selection and options such as All, Current Space, and None. Confirm their scope in the actual screen; do not assume that the currently visible rows are the only selected attachments.
Use the following proposed local sequence around those documented controls:
These controls do not establish a recycle bin, an undo guarantee, or a restorable full test-history backup. Do not rely on an unverified recovery route to make an unsafe deletion acceptable. An unexpected selection, unreadable export, missing approval, or unexplained source reference is a reason to stop before confirmation.
Consider an invented checkout project reviewing storage before another regression cycle. Its candidate list contains a reference image on a reusable Test step, a recording of an original failed checkout run, screenshots from the successful retest, and a video from an abandoned rehearsal. These are illustrative records, not an observed customer case or actions performed in a tenant.
The lead first distinguishes the Test-step reference from execution evidence. The reference still explains a condition testers must reproduce, so its age alone does not make it obsolete. The failed-run recording and retest screenshots support the defect's correction history. The responsible owner keeps them available under the project's retention decision, with their separate run and build references preserved.
The rehearsal video becomes a possible cleanup candidate only after the owner confirms that it supports no active investigation or required review. If a retained copy is required, the team verifies that copy and its context before approving removal. If its purpose cannot be established, it stays outside the approved selection. No storage saving is assumed merely because a candidate was identified.
For the next review, assign ownership before the storage limit becomes urgent. The useful outcome is a verified inventory and a defensible decision about each evidence class. Remove only what is approved, preserve what reviewers still need, and escalate a capacity constraint when retention requirements leave no safe cleanup option.
A green automated test history can help a developer identify a safe-looking change while leaving a QA lead unable to answer a different question:…
A checkout test appears under Payments, again in a Smoke folder, and once more under the latest release. When the payment rules change, someone…
A Jira story is Done, a test case is linked, and the related bug is Closed. Can the release owner conclude that the story's…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
