Starko

Page errors, groupedinto one bug ticket each.

Turn on one switch and the Starko widget reports uncaught JavaScript errors on your pages. Starko groups them, files a bug ticket once an error repeats, and keeps a running tally on that ticket instead of opening duplicates.

v2.starko.one/dashboard/tickets/c41a…
Tickets/NW-231
72%

/checkout: TypeError: Cannot read properties of undefined (reading 'total')

Open MediumUnassignedPage errorBugSmall

Page error reported by the Starko widget: 3 occurrences across 2 sessions since 2026-11-02 08:41 UTC

Error

Uncaught TypeError: Cannot read properties of undefined (reading 'total')

Stack

TypeError: Cannot read properties of undefined (reading 'total')
    at OrderSummary (https://app.northwind.io/_next/static/chunks/checkout-8f2a1c.js:1:20417)
    at renderWithHooks (https://app.northwind.io/_next/static/chunks/framework-1b4d.js:1:41290)

Where

  • Page: https://app.northwind.io/checkout?plan=team
  • Browser: Chrome 141 on macOS
  • Release: web@4.12.0
  • Client: Mia Novak (mia@northwind.io) · identity verified
  • Session replay: the recording plays in this ticket's Session replay panel

Source

  • Grouped by message + file + top stack frame; more occurrences land here as comments (one per hour at most). Nothing is sent to the fix agent until a person accepts this ticket.
  • Error group: 9c1f04be7a2d4e18b3a6c55e0d7f9a21

Session recording

app.northwind.io/checkoutPlay
2 hours ago1m 31s113JS error
Starko AIAI agent2 Nov at 10:12

Still happening: 14 occurrences across 9 sessions so far

Last seen: 2026-11-02 10:12 UTC · https://app.northwind.io/checkout · Safari 18 on iPhone · release web@4.12.0

At a glance

Error tracking in short.

Switch
Report page errors as tickets, in Settings under Starko AI. Off by default.
What is caught
Uncaught JavaScript errors and unhandled promise rejections on pages with the widget.
What is sent
Message, script URL, line and column, stack, page URL and your release. No form values or page content.
When a ticket is filed
When a second visitor hits the error, or it repeats within 24 hours.
Daily cap
At most 20 new tickets a day per workspace. After that only the counters move.
Updates
One Still happening comment on the ticket, refreshed at most once an hour.
Fixing
Never automatic. A person starts Starko AI from the ticket.
Session replay
Not required. With it on, the ticket plays the recording.
What is reported

Real errors from real visitors, without the noise.

With the switch on, the widget listens for uncaught errors and unhandled promise rejections on your pages and sends them to Starko in small batches. Errors nobody can act on are dropped before they leave the page, and the same error is sent at most once a minute per page.
  • Dropped as noise: cross-origin "Script error." without a stack, errors from browser extensions, ResizeObserver loops, aborted or failed network requests, and errors inside the Starko widget itself.
  • Sent: the message, script URL, line and column, stack trace, page URL and your release. No form values or page content.
  • Pass release to the widget (a git SHA or web@4.2.1) and every error says which build raised it.
  • Console errors are not reported. Only uncaught errors become tickets.
  • With session replay on, errors inside recordings feed the same groups. An error that arrives both ways counts once.
  • Only people who can change Starko AI settings can turn reporting on or off.
v2.starko.one/dashboard/settings/starko-ai
Settings/Starko AI
72%
Session replay

Record visitor sessions

The widget records your pages and keeps a short clip when something goes wrong: an error, a rage click, a conversation or a reported problem. Inputs are always masked. Starko AI reviews the clips and files recommendation tickets for you to accept. Off by default; hosts can also exclude a page with the widget's sessionReplay: false option.

Page errors

Report page errors as tickets

JavaScript errors the widget sees on your pages become bug tickets: grouped, deduplicated, and never sent to the fix agent until a person accepts them.

Grouping

One error, one group, whichever page it happens on.

Each error gets a fingerprint from its message, its script file and its top stack frame, with everything that changes between two occurrences of the same bug stripped out: line and column numbers, chunk hashes, ids, numbers and query strings. The page is not part of the fingerprint, so the same error on three pages is one bug. Grouping is plain rules, with no model call.
  • The title is the first page it was seen on plus the message, for example /checkout: TypeError: Cannot read properties of undefined.
  • The "Uncaught" prefix some browsers add is ignored, so the same error from the page and from a recording group together.
  • Each group counts occurrences and distinct visitor sessions, and keeps the first message and stack with the latest page, browser and release.
Filing

A ticket once an error repeats, never for a one-off.

The first occurrence only starts the group. A ticket is filed when a second visitor session hits the same error, or when it happens again within 24 hours of the first time. It is a regular bug ticket in your workspace, tagged Page error, so it shows up on the Tickets page with everything else.
  • Filed as Bug, Small, priority Medium, internal only, in the project you chose for customer tickets or your only project with a repository.
  • The description holds the error, the first frames of the stack, and where it happened: page, browser, release and the visitor, with "identity verified" when your site signed their identity.
  • When the session was recorded, the ticket's Session recording section plays it.
  • Text that comes from the visitor's page is escaped before it goes into the ticket.
  • At most 20 new page error tickets a day per workspace (UTC). Past that, groups keep counting and file on a later occurrence once the cap allows.
Running tally

Repeats update one comment instead of adding twenty.

Further occurrences land on the open ticket as one Starko AI comment that starts with Still happening: the total occurrences and sessions so far, when it was last seen, on which page, in which browser and release. Starko rewrites that comment in place, at most once an hour. If a person has commented since, the next update goes under their comment, so it is seen.
  • Automated comments in between, like a run's report, do not break the tally.
  • If the ticket is closed or archived and the error comes back, Starko files a new ticket that says it came back after being fixed and links the old one.
Starko AIAI agent2 Nov at 09:15

Still happening: 6 occurrences across 4 sessions so far

Last seen: 2026-11-02 09:15 UTC · https://app.northwind.io/checkout · Safari 18 on iPhone · release web@4.12.0

LPLuka Petrović2 Nov at 09:32

Only happens when the plan query param is set. Looking at the summary component.

Starko AIAI agent2 Nov at 10:12

Still happening: 14 occurrences across 9 sessions so far

Last seen: 2026-11-02 10:12 UTC · https://app.northwind.io/checkout · Safari 18 on iPhone · release web@4.12.0

From error to fix

A person decides when Starko AI takes it.

Page error tickets skip the triage classifier, so a project's auto-dispatch policy never sends them to the fix loop. When you want one fixed, press Fix with Starko AI on the ticket, or ask Starko AI for a fix in a comment. Starko AI then works in a cloud sandbox with the ticket, the stack and the recording when there is one.
  • The run ends in a pull request with its evidence, and merging it closes the ticket.
  • Page errors are bugs you already know the shape of. Friction without an error, where visitors get lost, is what Improvements is for.

FAQAbout Error tracking.

Keep exploring

Connect a channel and a repository. Turn the support queue into a build queue.

Feedback starts flowing in minutes. The first recommendation shows up as soon as a pattern repeats, and the first pull request as soon as you accept one.

Start for freeGet a demo