You can attach a video to an Azure DevOps work item, but only as a file: up to 100 attachments per item, each capped at 60 MB, and viewers have to download it to watch it. For a short screen recording of a bug, that works. For a long UAT session, it gets awkward quickly. This guide covers where video can live in Azure DevOps (work items, wikis, test runs), what the limits are, and how to keep video evidence useful instead of letting it become clutter.
TL;DR
- Work items accept video as an ordinary attachment: 100 per item, 60 MB each, and the limits are fixed.
- There is no inline player on a work item. Reviewers download the file, which slows triage.
- Wikis can embed video with the HTML video tag or the video markdown syntax, but wiki attachments have a tighter size cap than work items.
- Automated test runs can publish video through the
publishRunAttachmentssetting on the test tasks. - Short, focused recordings with a transcript, attached at the moment the issue is found, beat long uploads every time.
Table of Contents
- Where video can live in Azure DevOps
- Attaching video to a work item
- Videos on Wiki pages
- Video in automated test runs
- Why UAT teams outgrow raw attachments
- Rules that make video evidence worth attaching
- Our perspective
- A simpler flow for UAT video feedback
- Putting it together: a sample workflow
- FAQ
- Sources
Where video can live in Azure DevOps
Azure DevOps has three places where video shows up in practice, and each behaves differently. Mixing them up is the source of most “my video won’t play” threads.
| Location | How video gets there | Playback | Size limit |
|---|---|---|---|
| Work item attachment | Drag and drop or the Attachments tab | Download to watch | 60 MB per file |
| Wiki page | Embedded tag or markdown syntax | Plays in the page | 19 MB per wiki attachment |
| Test run results | Pipeline task publishes diagnostic files | Opened from the test results view | Governed by the test attachment rules |
The limits and behavior behind this table are sourced below, and we walk through each location next.
Attaching video to a work item
Open the work item, go to the Attachments tab, and drag the file in or browse for it. Microsoft’s documentation on managing work item attachments lists the available actions after upload: preview, add or edit a comment, copy the attachment link, download, delete and permanently delete.
The numbers that matter are on the work tracking limits page: 100 attachments per work item and 60 MB per attachment in Azure DevOps Services. Self-hosted Azure DevOps Server is different: its administrators can configure the maximum attachment size, so check with your admin before assuming the cloud numbers apply.
The preview gap
The preview option exists, but in practice it is aimed at images and text. Video files such as MP4 generally have to be downloaded before anyone can watch them. That is the friction behind the Developer Community threads where teams ask for video in comments and are told to attach the file and point people to the attachments tab.
In a UAT cycle that friction multiplies. A developer who has to open a ticket, download a file, find the right timestamp and then go back to the ticket will skip the video when the ticket is busy. Which is exactly when you needed it.
Staying under 60 MB
A 60 MB cap is generous for a focused clip and tight for a full session. Some practical ways to stay under it:
- Record only the failing flow. Thirty to ninety seconds usually shows the defect. Our guide to partial screen recording explains why capturing just the relevant area also cuts file size.
- Lower the capture resolution when fine detail is not the point.
- Split long sessions into one clip per defect, each attached to its own ticket.
- Link instead of attach when the file is large: store it in an approved location and paste the link into the work item.
If you do link out, treat access as part of the process. A link to a recording that the developer cannot open is worse than no link.
Videos on Wiki pages
Wikis are the better home for tutorials, test walkthroughs and training material. Per the Azure DevOps markdown guidance, you can use the HTML <video> tag with the controls attribute, or the dedicated video markdown syntax, which supports embedding from external platforms such as YouTube or Microsoft Stream. Local video files stored in the wiki’s attachments folder can be linked with markdown.
Two cautions. First, wiki files sit in a .attachments folder inside the wiki’s Git repository, and individual wiki attachments are limited to 19 MB, far below the work item limit. Second, because the files live in Git, large videos bloat the repository over time. For anything beyond short clips, embed from an external video platform your company already approves.
A wiki is not a bug tracker, though. Use it for reference material, and keep evidence for a specific defect on the defect itself.
Video in automated test runs
If your tests are automated, you can attach video without anyone touching a file. The VSTest task has a publishRunAttachments boolean, which uploads test run level attachments. The Azure Test Plan task has the same setting for uploading diagnostic files collected during the run. Both default to true, so check that nobody switched it off if your recordings are missing.
Firewall trouble with large test attachments
If you use self-hosted agents behind a firewall, large test attachments can fail with 403 or 407 errors. Microsoft’s Sprint 156 release notes explain that support for attachments over 100 MB was added and that the fix is to allow the https://*.vstmrblob.vsassets.io domain. Ask your network team to add it before you blame the pipeline.
Note that this covers automated runs. UAT is mostly manual, run by business users who do not write pipelines, so the work item route is the one that matters for them.
Why UAT teams outgrow raw attachments
UAT testers are business users, not engineers. They find a problem, and they want to show it. The native route asks them to record with one tool, find the file, rename it, open Azure DevOps, create the item, fill the fields, and attach the file. Every step is a chance to drop the evidence or to write a vague title.
There are also governance problems on the other side. Microsoft’s Q&A thread on work item attachment storage notes that the documentation focuses on per-item limits and does not clearly describe organization-level behavior. For a QA manager, that means little visibility into how much evidence has piled up, and no obvious way to plan clean-up of stale recordings.
And there is the duplicate problem. When ten testers hit the same defect, ten recordings land in ten tickets, each 40 MB, none of them linked. Triage then spends its time comparing downloads.
Rules that make video evidence worth attaching
Whatever tooling you use, these habits keep video useful. They draw on the same thinking as our rules for bug report attachments.
- One defect, one clip. Never bundle several bugs in one file.
- Say what you expected. Either narrate it or write it in the ticket. A clip that shows a screen with no stated expectation makes the developer guess.
- Put a timestamp in the description for the moment the failure occurs.
- Include the environment and build. Our checklist of UAT environment requirements shows what to verify first.
- Mind what is on screen. Recordings can capture customer data and credentials. Read UAT video privacy by design and the notes on redacting screen recordings before sharing widely.
- Search before you file. A duplicate with a video is still a duplicate.
- Decide a retention rule. Delete or archive evidence once a defect is closed and signed off.
Our perspective
We built Wezard because the video itself was never the problem. The handoff was. A tester records the issue, then spends minutes turning it into a ticket, and the developer then spends minutes working out what the tester meant.
So we put the recording, the transcript and the ticket in one motion. The tester records the screen and describes the problem out loud. Wezard transcribes it in real time and builds an enriched ticket. Before it reaches Azure DevOps, AI checks whether the same issue is already in the backlog, which is how we cut duplicate noise, by up to 40% compared with manual processes or basic feedback tools.
We think the right model is that the backlog holds one clean, well-evidenced ticket per defect, not a pile of attachments to download. Native attachments remain useful for logs, spreadsheets and one-off files. For the bulk of UAT feedback, the evidence should be watchable and searchable where the team already works.
— Marketing
A simpler flow for UAT video feedback
If your testers are business users and your backlog is in Azure DevOps, Wezard’s Azure DevOps integration lets them record, speak and submit without learning the work item form. Tickets arrive with the recording and transcript, and likely duplicates are flagged before they reach the backlog. You can see how it fits a full test cycle in our UAT testing feedback tool overview.
Plans are published on the pricing page: Starter at 25 $ per month, Team at 70 $ per month, Business at 160 $ per month, and Enterprise with no published price. Wezard is SOC 2 certified and supports SSO on enterprise plans, which is usually what security reviewers ask about first when screen recordings are involved.
Putting it together: a sample workflow
Here is how a team of eight testers might run a two-week UAT with video evidence in Azure DevOps.
- Before testing starts, agree on the clip rule: one defect, under two minutes, narrated.
- During testing, testers record the failing flow right when it happens, not afterward from memory.
- At submission, the ticket carries the clip, a short transcript and the build number.
- At triage, the QA lead checks flagged duplicates first and merges them. Our 7 to 14 day plan to cut duplicate UAT tickets covers this step in detail.
- After the fix, the tester re-tests and records a short passing clip, so sign-off has proof. See how to sign off on test cases after UAT.
- At close, archive or delete the evidence under your retention rule.
For broader process advice, our Azure DevOps bug reporting best practices and Azure DevOps UAT guide go further, and documenting issues with screen recording covers capture technique.
FAQ
How big can a video attachment be in Azure DevOps?
In Azure DevOps Services, each work item attachment is limited to 60 MB, with up to 100 attachments per work item. Wiki attachments are stricter, at 19 MB each. On Azure DevOps Server, administrators can configure the size.
Can I play a video directly inside a work item?
Not reliably. Preview is geared toward images and text, so MP4 files normally need to be downloaded. If your team needs inline playback, embed the video on a wiki page or use a tool that stores and plays the recording alongside the ticket.
How do I embed a video on an Azure DevOps wiki page?
Use the HTML video tag with the controls attribute, or the video markdown syntax for platforms such as YouTube or Microsoft Stream, as described in the markdown guidance. Local files in the wiki’s attachments folder can also be linked, within the 19 MB limit.
How do I get video evidence into automated test results?
Make sure publishRunAttachments is true on your VSTest or Azure Test Plan task. If uploads fail on self-hosted agents with 403 or 407 errors, ask your network team to allow the blob domain named in the release notes.
Sources
- Manage work item attachments, Microsoft Learn
- Work tracking, process, and project limits, Microsoft Learn
- Markdown syntax for files, widgets, wikis, Microsoft Learn
- Wiki file and folder structure in Git, Microsoft Learn
- VSTest@1 task, Microsoft Learn
- AzureTestPlan@0 task, Microsoft Learn
- Azure DevOps Sprint 156 release notes, Microsoft Learn
- Work item attachments question, Microsoft Q&A
