Reading a Report
Every run produces a report — per-step screenshots, timestamped logs, a video recording and DT usage.
Every run produces a report: what each step did, what the screen looked like before and after, what Drizz decided, and what it cost.
Platforms
Android · iOS
Every report has
Per-step status · before/after screenshots · timestamped logs · DT usage
Three types
Standard · Debug · Accessibility
Links
Signed and time-limited — they expire
Prerequisites
A completed run, local or cloud
Access to the project the run belongs to
What's in every report
Per-step status
Passed, failed, healed or skipped, for every step in order
Before and after screenshots
The screen going into the step, and coming out of it
Timestamped logs
What Drizz decided at each step and why, with the duration
A video recording
The whole run, downloadable from the Actions section — see Recordings
Token usage
DT spent on the run
The device that ran it
Model and OS version
Steps that resolved from cache are marked "Predicted Action drizzing fast ⚡" — see Caching. Steps repaired mid-run carry a healed badge — see Self-healing.
Read a report
Read the run status:
Passed,Passed (healed),Failed,ErrororBlocked.ErrorandBlockedare not test failures — see Statuses.Read the healed-step count, including on a green run. Healed steps have weak descriptions.
Open the first failing step, not the last. A cascade of failed steps has one cause at the top.
Open that step's before-screenshot and compare it against the screen the step expected — see When a step fails.
Open the video only if the stills don't explain the failure. Use it for timing, animation and navigation problems.
Report types
The run, step by step, with before and after screenshots, timestamped logs, the recording and DT usage.
This is the default report and is produced for every run.
Adds deeper diagnostic detail beyond the standard report.
Applies when the standard report does not explain a failure.
Adds accessibility findings from the run, alongside the functional result.
Drizz validates what is visually rendered. It does not do WCAG conformance scanning, screen reader testing, contrast analysis, or semantic and role-level validation — see Known limitations.
Sharing a report
Report links are signed and time-limited. They open for anyone holding the link until the link expires, then stop.
Share for immediate review — a message, a live triage call
✅
Attach to a ticket or a release record
Link
Getting results out
There is no export format. Reports cannot be exported as JUnit XML, JSON or Allure, so CI systems cannot ingest results directly. With no run-status endpoint, a pipeline can trigger a Drizz run but cannot wait on it or gate a build on the outcome. Artifacts download by hand from the Actions section.
Common mistakes
Debug the last red step
It's a consequence. The first failing step is the cause
Read Passed (healed) as Passed
The suite is held together by repairs and the pass rate hides it
Paste a report link into a ticket as the evidence
The link expires and the ticket becomes unusable. Attach the artifacts
Open the debug report first
The standard report's before-screenshot answers most failures faster
Treat Error as a test failure
It's infrastructure, not your test. Re-run it before investigating
Expect CI to parse the report
No export format exists. There is nothing to parse
Next
Last updated: 6 August 2026
Last updated
Was this helpful?