Rank Broken Sessions With an OpenAI dots Plugin for Session Analysis

An always-on agent suits one analytics job better than the rest, and an OpenAI dots plugin for session analysis is that job: reading the issue list Flowsery builds from session recordings every morning and telling you which three to open. The dot never watches a replay. It ranks, narrows and hands you recording IDs. Setup, the developer mode URL and the OAuth sign-in are in the OpenAI dots plugin for web analytics guide; this post points the plugin at issues.

The short version: save a weekday task that lists open critical and high issues, re-ranks them by sessionsCount, and reads the detail for the top three. Three reads, and PATCH /issues/{issueId} stays off limits.

What does a dot see when it opens a Flowsery issue?

A dot sees the issue record Flowsery produced, not the recording behind it. Each record in GET /issues carries a title, a description, a severity, a status, sessionsCount, firstSeenAt, lastSeenAt, ordered stepsToReplicate, a nullable sampleRecordingId and any linked external ticket. GET /issues/{issueId} adds the flagged occurrences with an atSeconds offset, the sessions behind the issue with their recording IDs, and your team's comments.

Severity takes low, medium, high and critical, and status takes open, in_progress, resolved and suspended. GET /issues sorts by severity unless you pass sort=recency. The comments are worth teaching the dot early: they separate a drop-off nobody has seen from one a teammate looked at last Thursday.

Can a dot watch a session replay?

A dot cannot watch a replay through the plugin, because Flowsery's API returns JSON, not video. The closest thing is the occurrences array: each flagged moment carries a description, a severity and the second it happens at. So a dot can tell you a rage click cluster hit 41 sessions, read out the steps to reproduce it and name the recording that shows it best. It cannot tell you the submit button looked greyed out.

The dot's own Chrome browser is the tempting workaround. A dot can open the Flowsery dashboard in its own browser once you sign it in, and OpenAI's secure sign-in pauses the model while you type and keeps credentials out of the dot's context. Two problems remain. OpenAI does not document how a dot reads a replay player, and a signed-in browser carries your full dashboard access, which is wider than a Viewer plugin sign-in. Keep watching the replay as your job.

Which session calls read, and which one writes?

Four session endpoints matter, and exactly one changes data: PATCH /issues/{issueId} moves an issue between statuses, which is the whole supervision problem.

Three layers keep that write away from a dot. On ChatGPT Pro, OpenAI's August help article says custom MCP gets "read/fetch permissions", so the write tool is out of reach before anything else applies. On Business Premium, full MCP brings it back, and Custom Rules set to "Ask before taking action" put a question in front of it. Under both, a Flowsery sign-in with the Viewer role gets a 403 permission_denied on the PATCH, because only Admins and Editors hold flowsery.write.

Should a dot be allowed to change an issue's status?

Keep issue status changes away from a dot for its first month, and away from every schedule after that. A resolved issue leaves the list everyone opens in the morning, and a suspended one drops out of the default GET /issues response until somebody asks for status=suspended. Status hygiene is the chore an agent looks good at: a sweep that moves twelve stale criticals to resolved produces a shorter list with the same broken checkout underneath it.

Always-on makes this sharper for a dot than for a chat agent. A dot works while you sleep, and OpenAI's safety post names sending messages and sharing files as the actions a dot seeks authorization for; changing a record in another app is not on that list. OpenAI gives you two ways to watch: the Activity View lists current and delegated tasks, and monitoring can pause or stop the dot's work. Read both before you widen anything.

What should the morning triage task say?

The morning triage task needs to name the website, the ranking rule and the ban on writes, because a dot fills every gap with its own judgment. Paste this and change the names:

Every weekday at 08:30 Europe/Berlin, triage Flowsery issues for acme.com
in the Acme workspace. Use the Flowsery plugin only, never the browser.
Read only: never change an issue's status.
 
1. List open issues with severity critical or high.
2. Re-rank them by sessionsCount, highest first. Print severity and
   sessionsCount next to every title.
3. For the top three, get the issue detail: steps to replicate, the sample
   recording id, and the second of the first occurrence.
4. Skip any issue with a team comment from the last 7 days.
5. If an issue has no sample recording, say so. Do not pick another one.
6. Do not visit acme.com to reproduce anything.

Line 2 comes from Flowsery's own advice in its read-only MCP worker: the API sort order is not impact, and its example sets a medium issue that hit 140 sessions against a critical that hit 3. Line 6 is the dot-specific one, and the next section explains it.

Does a dot reproducing a bug end up in your recordings?

A dot that follows stepsToReplicate on your live site does it in a real Chrome browser on OpenAI's Linux machine, and whether Flowsery records it depends on one flag OpenAI has not documented. Flowsery's tracker and its session recorder both skip any browser that reports navigator.webdriver as true. OpenAI's dots documentation, checked 29 September 2026, names no user agent, no IP range, and says nothing about that flag.

If the flag is set, Flowsery drops the visit. If it is not, the dot's reproduction is recorded like any visitor's session, next to the real sessions Flowsery builds issues from. A checkout reproduction on production also reaches a payment step, and OpenAI says purchases need your approval. Reproduce on a staging site, and run the visibility test in the web analytics guide once so you know which outcome applies to you.

What breaks on session analysis with a dot?

Five things break issue triage, and the fourth one looks like an answer.

1. A trial account hides issues. On a Flowsery free trial, AI-detected issues beyond the first 10 answer "Upgrade to view this issue". The dot reports the message, not the issue.
2. The website selector is missing. A credential that spans more than one website needs websiteId or domain on every call, and a selector that matches nothing returns 404 Website not found. Put the domain in the task.
3. The visitor id is invented. GET /visitors/{visitorId} takes the _fs_vid value Flowsery's tracker sets, and GET /realtime/map returns visitor IDs for people on the site now. A guessed id returns 404 Visitor not found.
4. The ranking gets rewritten. A summary reorders issues by what reads well. Printing severity and sessionsCount beside each title keeps the order checkable.
5. A 429 mid-sweep. Flowsery allows 600 requests a minute per key, and every response carries RateLimit-Remaining and RateLimit-Reset. Tell the dot to wait out Retry-After instead of retrying blind.

The same loop runs on other agents too. The Meta Muse connector for session analysis builds it from the public spec, and the Grok bot template for session analysis ships it as a skill. The issues all three read come from Flowsery's session replay tool.

Frequently Asked Questions

Can a dot close a Flowsery issue on its own?

Only if three layers let it. ChatGPT Pro limits custom MCP to read/fetch under OpenAI's August help article, Custom Rules can hold every action for your approval, and a Flowsery Viewer sign-in gets a 403 on PATCH /issues/{issueId}. Keep all three in place for the first month.

Can a dot trigger triage when a new critical issue appears?

Not through an event trigger yet. OpenAI's event triggers need a connected service that supports event monitoring, and Flowsery's MCP docs describe none as of 29 September 2026. A weekday task at a fixed time is the fallback, so a critical that appears at 09:00 waits for the next morning's run.

What does a dot see about a visitor?

GET /visitors/{visitorId} returns location, browser, device, activity, revenue and a profile with userId, name and email once your site has called identify. Flowsery stores no IP addresses and sets no cross-site identifiers. Decide before you allow the call whether a dot, whose memories you cannot view or edit, gets that data.

Does this replace opening the replay?

No. The dot ranks and narrows, and the recording is where the reason lives. Let the dot pick the three sessions worth ten minutes, then spend the ten minutes yourself.

Why is a suspended issue missing from the dot's list?

GET /issues leaves suspended issues out of the default response until you ask for status=suspended. If an issue vanished and nobody on your team moved it, check the tasks the dot ran in its Activity View.

Which Flowsery plan does a triage dot need?

Either one. GET /issues and the AI session analysis behind it are on both Team at $250 a month and Pro at $500, each with a 14-day free trial that needs no card. On the trial, only the first 10 issues open in full.

Should a dot use its own browser for triage?

Keep it on the plugin. A signed-in browser carries your full dashboard access, which is wider than a Viewer plugin sign-in, and OpenAI does not document how a dot reads a replay player. Put "Use the Flowsery plugin only, never the browser" in the task text.

How do I rank issues by impact instead of severity?

Tell the dot to re-rank by sessionsCount. GET /issues sorts by severity unless you pass sort=recency, and neither is impact. Flowsery's own example sets a medium issue that hit 140 sessions against a critical that hit 3.

What should a dot do when it hits a rate limit?

Tell it to wait out Retry-After instead of retrying blind. Flowsery allows 600 requests a minute per key, and every response carries RateLimit-Remaining and RateLimit-Reset.

Why does a dot answer "Upgrade to view this issue"?

That is the message a Flowsery free trial returns for AI-detected issues beyond the first 10. The dot reports the message, not the issue. During the trial, only the first 10 issues open in full.

Start a Flowsery trial and run a read-only issue sweep, or read the API reference first.

Sources: Introducing dots, How we build safety, security and privacy into dots, the DevDay 2026 recap, OpenAI help on safety, the dots user docs, OpenAI's MCP help article (updated August 2026), the Flowsery API reference, the Flowsery OpenAPI spec and Flowsery's read-only MCP worker. Checked 29 September 2026.