Can I share a BrowserStack session with someone outside my team?

BrowserStack offers public links for individual sessions, but they are per-session, time-bounded and only cover one run. For a client or a stakeholder who needs the whole picture, publish a summary page with the failing sessions embedded.

Why do BrowserStack links go dead?

Session artifacts — video, logs, screenshots — are retained for a limited window depending on plan. A link pasted in a ticket six months ago usually resolves to nothing.

What belongs on a published cross-browser report?

The matrix of browsers and devices tested, which combinations failed, the screenshot or video link for each failure, and the console output. A client wants the matrix; an engineer wants the logs.

Does this work for App Automate too?

Yes. Real-device app sessions have the same access and retention limits, so the same summary-page pattern applies.

How do reviewers respond?

By commenting on the failing combination. 'Safari 16 is out of scope for this contract' next to the Safari 16 row settles it in one exchange.

Share a BrowserStack test run

The regression suite ran across eleven browser and device combinations. Two failed — Safari 16 on iOS and an older Samsung Internet — and BrowserStack has the video, the console log and the screenshot for both.

The client's QA contact wants to see it. They do not have a seat on your BrowserStack account, and you are not adding them to it.

Two limits, not one

Access. Session details live behind your account. Public links exist but are per-session: eleven combinations means eleven links and no overview, which is exactly the shape nobody reads.

Retention. Session artifacts age out. The link you put in a Jira ticket is a working reference for a few weeks and a dead end afterwards — the same disappointment as an expired CI artifact.

Publish the matrix

What a stakeholder actually needs is one page: what was tested, what failed, and what the failure looked like.

<h1>Cross-browser regression — release 2.14</h1>
<p>11 combinations · 9 passed · 2 failed</p>

<table>
  <tr><th>Browser / device</th><th>Result</th><th>Notes</th></tr>
  <tr><td>Chrome 141 · Win 11</td><td>Pass</td><td></td></tr>
  <tr><td>Safari 16 · iPhone 13</td><td class="fail">Fail</td>
      <td>Date picker does not open</td></tr>
</table>

<h2>Safari 16 · iPhone 13</h2>
<img src="…failure.png" alt="Date picker fails to open" />
<pre><!-- console output --></pre>

The table is what the client reads. The screenshots and logs underneath are what their engineer reads. Both on one URL, which still works next quarter because the summary is yours rather than BrowserStack's.

Scope arguments end faster

The most common reply to a cross-browser report is not about the bug. It is "do we even support Safari 16?"

On a published page that question arrives as a comment on the Safari 16 row and is answered there, permanently, where the next person to ask will find it — see commenting on HTML. In email it gets re-litigated every release.

Publish it from the pipeline

- run: npm run test:browserstack
- run: node scripts/publish-matrix.js   # builds the page, updates one report

Updating a single report id per release branch means one URL for "the current cross-browser status", with the whole comment history attached. See publishing from CI.

Worth knowing

Embed screenshots, link videos. Video does not belong in a report body; a link plus a still keeps the page fast.
Restrict the report. Screenshots of a pre-release app are not something to leave on an open link — see security.
5 MB per report body.

Try it

Free — unlimited reports, commenters and revisions.

Publish from CI →