Error Tracking
Automatically detect, group, and investigate application errors with AI-powered analysis.
What Error Tracking Does
Bosca automatically captures JavaScript errors that occur in your web application — unhandled exceptions, failed promises, and runtime errors. Instead of presenting you with a raw list of thousands of individual error events, the system intelligently groups similar errors together so you can focus on distinct issues rather than individual occurrences.
Each error group gives you a consolidated view: what the error is, when it first appeared, when it last occurred, how many times it has happened, and a representative example with the full error details. This turns a flood of error notifications into a manageable list of actionable issues.
Error Groups
When an error occurs, the system examines three characteristics to determine which group it belongs to:
- Application — Which application produced the error. Errors from different applications are always kept separate.
- Error type — The kind of error (for example, TypeError, ReferenceError, or a custom error name).
- Call path — The sequence of function calls that led to the error, with minor variations like line numbers removed so that the same bug is recognized even after code is redeployed.
These three characteristics are combined into a fingerprint — a unique identifier for that class of error. Every time the same kind of error occurs again (same app, same error type, same call path), it is added to the existing group rather than creating a new one.
Each error group tracks:
| Field | What It Tells You |
|---|---|
| Error type and message | What kind of error it is and the error message from the first occurrence |
| Application | Which application produced the error |
| Fatal flag | Whether the error crashed the application or was handled gracefully |
| First seen / Last seen | When the error first appeared and when it most recently occurred |
| Event count | Total number of times this error has occurred |
| Sample event | A representative error event with full details for investigation |
| Status | Current workflow status: Open, Resolved, or Ignored |
| Assignee | The team member responsible for investigating or fixing the error |
| AI summary | AI-generated root-cause analysis, if requested |
Error Status Workflow
Every error group moves through a simple lifecycle that helps your team track progress on fixing issues:
| Status | Meaning | What Happens Next |
|---|---|---|
| Open | A new or recurring error that needs attention. All new error groups start here. | Can be marked as Resolved (when fixed) or Ignored (when intentionally suppressed). |
| Resolved | The error has been fixed and is no longer expected to occur. | If a new event matches the same fingerprint, the group automatically reopens to alert you that the fix may not have worked. |
| Ignored | The error is intentionally suppressed — it is a known issue you have decided not to fix. | New occurrences are still counted, but the status does not change. You can reopen it at any time. |
Assigning Errors to Team Members
Error groups can be assigned to specific team members to track who is responsible for investigating and fixing each issue. Assignment works independently of status — you can assign an error that is open, resolved, or ignored.
A typical workflow:
- A new error group appears with status Open
- A team lead reviews it and assigns it to the appropriate developer
- The developer investigates, deploys a fix, and marks the error as Resolved
- If the error reoccurs, it automatically reopens and the assigned developer is alerted
AI-Powered Root-Cause Analysis
Every error group has a one-click AI analysis feature. When you trigger an analysis, an AI agent examines the error and produces a human-readable summary of what went wrong and what to do about it.
The AI analysis considers:
- The error type and error message
- The stack trace showing where the error occurred
- How frequently the error occurs and when it first appeared
- The environmental context from the sample event (browser, page, device)
The result is a plain-language summary that explains the likely root cause and suggests next steps. This is especially helpful when:
- You are triaging an unfamiliar error and need a quick understanding of what it means
- You need to decide which team member to assign the error to
- You want to assess the severity and urgency of an error without diving into code
Filtering and Searching Errors
The error tracking interface provides several ways to find the errors you care about:
- Filter by application — Focus on errors from a specific application when you have multiple apps
- Filter by status — See only Open errors that need attention, or review Resolved errors to check they have not come back
- Filter by severity — Show only fatal errors (those that crash the application) or non-fatal errors (those that were handled but still logged)
- Text search — Search across error types and messages to find errors related to a specific feature or component
Filters can be combined. For example, you can search for all open, fatal errors in a specific application that mention "network" in the error message.
How Error Tracking Connects to Analytics
Error tracking is fully integrated with the rest of the analytics system. Error events flow through the same ingestion pipeline as all other events, which means:
- Error events are enriched with geographic data, so you can see where errors are occurring
- Error data is stored alongside all other analytics events and can be queried using the query system
- You can build visualizations that display error trends, error rates by page, or error breakdowns by browser
- Error metrics can be included on dashboards alongside traffic, engagement, and business metrics for a complete operational view