mirror of
https://github.com/BillyOutlast/posthog.com.git
synced 2026-02-04 03:11:21 +01:00
Init error tracking guides and concepts (#12404)
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com> Co-authored-by: Hugues Pouillot <hpouillot@gmail.com> Co-authored-by: David Newell <david@posthog.com> Co-authored-by: Andy Vandervell <92976667+andyvan-ph@users.noreply.github.com> Co-authored-by: Ian Vanagas <34755028+ivanagas@users.noreply.github.com> Co-authored-by: PostHog <hey@posthog.com> Co-authored-by: edwinyjlim <edwinyjlim@gmail.com> Co-authored-by: Edwin Lim <edwin@posthog.com>
This commit is contained in:
Vincent (Wen Yu) Ge
committed by
GitHub
GitHub
parent
93e1f1c776
commit
d0c7a152a5
17
contents/docs/error-tracking/_snippets/before-send-hook.mdx
Normal file
17
contents/docs/error-tracking/_snippets/before-send-hook.mdx
Normal file
@@ -0,0 +1,17 @@
|
||||
You can use the [`before_send`](/docs/libraries/js/features#amending-or-sampling-events) callback in the [web](/docs/libraries/js) and [Node.js](/docs/libraries/node) SDKs to exclude any exception events you do not wish to capture. Do this by providing a `before_send` function when initializing PostHog and have it return a falsey value for any events you want to drop.
|
||||
|
||||
```js
|
||||
posthog.init('<ph_project_api_key>', {
|
||||
before_send: (event) => {
|
||||
if (event.event === "$exception") {
|
||||
const exceptionList = event.properties["$exception_list"] || []
|
||||
const exception = exceptionList.length > 0 ? exceptionList[0] : null;
|
||||
|
||||
if (exception && exception["$exception_type"] === "UnwantedError") {
|
||||
return false
|
||||
}
|
||||
}
|
||||
return event
|
||||
}
|
||||
})
|
||||
```
|
||||
17
contents/docs/error-tracking/_snippets/burst-protection.mdx
Normal file
17
contents/docs/error-tracking/_snippets/burst-protection.mdx
Normal file
@@ -0,0 +1,17 @@
|
||||
The JavaScript web SDK uses burst protection to limit the number of autocaptured exceptions that can be captured in a period. This prevents an excessive amount of exceptions being captured from any one client, typically because they're being thrown in an infinite loop.
|
||||
|
||||
By default, we capture 10 exceptions (bucket size) of the same type within a 10 second period before the rate limiter kicks in, after which, we capture 1 exception (refill rate) every 10 seconds.
|
||||
|
||||
Often not needed, but you can change the bucket size and refill rate as part of your configuration:
|
||||
|
||||
```js
|
||||
import posthog from 'posthog-js'
|
||||
|
||||
posthog.init('<ph_project_api_key>', {
|
||||
api_host: '<ph_client_api_host>',
|
||||
error_tracking: {
|
||||
__exceptionRateLimiterRefillRate: 1
|
||||
__exceptionRateLimiterBucketSize: 10
|
||||
}
|
||||
})
|
||||
```
|
||||
@@ -0,0 +1,9 @@
|
||||
| Name | Key | Example value |
|
||||
|-----------|------|-------------|
|
||||
| `$exception_list` | List | A list of exceptions that occurred. In languages that support chained exceptions, the list will contain multiple items. Contains the following properties: |
|
||||
| └─ `type` | String | The type of exception that occurred |
|
||||
| └─ `value` | String | The message of the exception that occurred |
|
||||
| └─ `stacktrace` | Object | Contains a list of stack frames that occurred |
|
||||
| └─ `mechanism` | Object | If the stacktrace is handled and if it's synthetic |
|
||||
| `$exception_fingerprint` | String | A fingerprint of the exception |
|
||||
| `$exception_level` | String | The level of the severity of the error |
|
||||
@@ -0,0 +1,8 @@
|
||||
If the unwanted exceptions are being grouped under the same issue, you can suppress them so that subsequent exception events are not ingested. Issues can be suppressed from the list or issue page by changing their status to **Suppressed**.
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/suppress_issue_light_ef0e5156a9.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/suppress_issue_dark_dc96ef44b2.png"
|
||||
alt="Issue suppression status"
|
||||
classes="rounded"
|
||||
/>
|
||||
14
contents/docs/error-tracking/_snippets/merging-issues.mdx
Normal file
14
contents/docs/error-tracking/_snippets/merging-issues.mdx
Normal file
@@ -0,0 +1,14 @@
|
||||
You can merge issues representing the same problem from the issue list by:
|
||||
|
||||
1. Selecting the primary issue others should be merged into
|
||||
2. Selecting the issue(s) to merge into the primary issue
|
||||
3. Clicking the **Merge** button
|
||||
|
||||
After merging, all events and aggregated counts from the merged issues are added to the primary issue. The merged issues are then deleted (but the underlying events are not).
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/merge_light_0489da02c6.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/merge_dark_aab4bfcc93.png"
|
||||
alt="Error tracking issue merging"
|
||||
classes="rounded"
|
||||
/>
|
||||
@@ -0,0 +1,8 @@
|
||||
Autocaptured exceptions can be ignored client-side by [configuring suppression rules](https://app.posthog.com/error_tracking/configuration?tab=error-tracking-exception-autocapture#selectedSetting=error-tracking-exception-autocapture). Because the stack of an exception may still be minified client-side, you can only filter based on the exception type and message attributes.
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/suppression_rule_light_8db44eb6b1.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/suppression_rule_dark_5972d57398.png"
|
||||
alt="Issue suppression rules"
|
||||
classes="rounded"
|
||||
/>
|
||||
@@ -1,16 +1,16 @@
|
||||
---
|
||||
title: Error tracking alerts
|
||||
title: Send error tracking alerts
|
||||
---
|
||||
|
||||
To stay on top of issues, you can set up alerts. These enable you to post to Slack, Discord, Teams, or an HTTP Webhook when an issue is created or reopened.
|
||||
|
||||
## Issue created or reopened
|
||||
|
||||
To alert when an issue is created or reopened, go to [error tracking's configuration page](https://us.posthog.com/error_tracking/configuration) and click **Alerting**. This shows you a list of existing alerts. Clicking **New notification** brings you to a page to create a new one.
|
||||
To alert when an issue is created or reopened, go to [error tracking's configuration page](https://app.posthog.com/error_tracking/configuration?tab=error-tracking-alerting#selectedSetting=error-tracking-alerting) and click **Alerting**. This shows you a list of existing alerts. Clicking **New notification** brings you to a page to create a new one.
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/Clean_Shot_2025_04_08_at_11_53_54_2x_81605f7812.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/Clean_Shot_2025_04_08_at_11_53_11_2x_8b15ee84e0.png"
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/error_alerts_create_light_1a05deef21.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/error_alerts_create_dark_7585087b18.png"
|
||||
alt="Error tracking alerting"
|
||||
classes="rounded"
|
||||
/>
|
||||
@@ -21,7 +21,7 @@ This will then send alerts to your chosen destination when an issue is created o
|
||||
|
||||
|
||||
|
||||
### Alert filtering
|
||||
## Issue properties and assignments
|
||||
|
||||
You can filter an alert based on the properties of an issue. This is useful for notifying a specific team when they have been auto assigned an issue using [auto assignment rules](/docs/error-tracking/managing-issues#auto-assignment-rules).
|
||||
|
||||
@@ -40,13 +40,13 @@ Since error tracking works by capturing `$exception` events, PostHog features th
|
||||
|
||||
The first way is using [real time destinations](/docs/cdp/destinations). This enables you to send events (like `$exception`) to other tools as soon as they are ingested.
|
||||
|
||||
To create a real time destination, go to the [data pipelines tab](https://us.posthog.com/pipeline/overview) in PostHog, click **+ New**, and then select **Destination**. Choose your destination and press **+ Create**.
|
||||
To create a real time destination, go to the [data pipelines tab](https://app.posthog.com/pipeline/overview) in PostHog, click **+ New**, and then select **Destination**. Choose your destination and press **+ Create**.
|
||||
|
||||
On the destination creation screen, make sure to add an event matcher for the `$exception` event, filter for the properties you want, and set the trigger options.
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/Clean_Shot_2025_04_08_at_14_13_50_2x_8ca29f29f2.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/Clean_Shot_2025_04_08_at_14_14_04_2x_dcbf8f025e.png"
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/http_error_alert_light_9898376c56.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/http_error_alert_dark_7705f0e575.png"
|
||||
alt="Real time destination"
|
||||
classes="rounded"
|
||||
/>
|
||||
@@ -66,4 +66,12 @@ Here you can set alerts for event volume value, increase, or decrease.
|
||||
classes="rounded"
|
||||
/>
|
||||
|
||||
This sends an email notification to the user you choose. Check out our [alerts docs](/docs/alerts) for more information.
|
||||
This sends an email notification to the user you choose. Check out our [alerts docs](/docs/alerts) for more information.
|
||||
|
||||
import { CalloutBox } from 'components/Docs/CalloutBox'
|
||||
|
||||
<CalloutBox icon="IconInfo" title="Can't find your alert?" type="fyi">
|
||||
|
||||
If you'd like a destination to be added that we don't yet support, [let us know in-app](https://app.posthog.com/project/2#panel=support%3Afeedback%3Aerror_tracking%3A%3Afalse).
|
||||
|
||||
</CalloutBox>
|
||||
|
||||
71
contents/docs/error-tracking/assigning-issues.mdx
Normal file
71
contents/docs/error-tracking/assigning-issues.mdx
Normal file
@@ -0,0 +1,71 @@
|
||||
---
|
||||
title: Assign issues to teammates
|
||||
---
|
||||
|
||||
Error tracking enables you to assign issues to specific PostHog [roles](https://app.posthog.com/settings/organization-roles) or teammates. This helps your team find relevant issues through **filtering**. You can also set up team-specific **alerting** to notify them when assigned issues are created or reopened.
|
||||
|
||||
|
||||
## Assigning issues
|
||||
|
||||
You can manually assign issues as you triage them in the UI. This can be done both in the issue list and issue detail pages.
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/assignment_ui_light_109b2bf454.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/assignment_ui_dark_4682b2ac80.png"
|
||||
alt="Error tracking assignment UI"
|
||||
classes="rounded"
|
||||
/>
|
||||
|
||||
1. In your error tracking [issue list](https://app.posthog.com/error_tracking), click the **unassigned** selector under each issue to assign it to a role or user.
|
||||
|
||||
2. On the detail page of each issue, click the **Assignee** selector to assign it to a role or user.
|
||||
|
||||
Want to assign issues to a **team** rather than an individual teammate? You can create a role in [your project settings](https://app.posthog.com/settings/organization-roles).
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/roles_light_6c7ea17be9.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/roles_dark_f721b94577.png"
|
||||
alt="Error tracking role assignees"
|
||||
classes="rounded"
|
||||
/>
|
||||
|
||||
## Automatic issue assignment
|
||||
|
||||
You can set up automatic issue assignment through a set of rules. This can be configured in the [error tracking settings](https://app.posthog.com/error_tracking/configuration?tab=error-tracking-auto-assignment#selectedSetting=error-tracking-auto-assignment) using **auto assignment rules**.
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/assignment_rules_light_1cf9a2437a.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/assignment_rules_dark_11e0830b0c.png"
|
||||
alt="Error tracking auto assignment rules"
|
||||
classes="rounded"
|
||||
/>
|
||||
|
||||
Assignment conditions are evaluated against the properties of the exception event that created the issue. Because assignment rules are evaluated during ingestion, the stack trace (if present) will be unminified, which enables filtering on exception properties such as function name and source file.
|
||||
|
||||
Issues can be automatically assigned to a **role** or **user** by configuring a set of filters. These filters can be configured to match **any** or **all** of the criteria.
|
||||
|
||||
You can configure automatic assignment to filter on any [event property](/docs/data/events) in PostHog. When there are multiple values for a property, the filters return true if it matches **any** of the values. For example, if you have multiple `exception_functions` values, the filters returns true if it matches **any** of the functions.
|
||||
|
||||
Here are some common properties you can filter on:
|
||||
|
||||
| Property | Event property | Description |
|
||||
| --- | --- | --- |
|
||||
| Exception type | `$exception_types` | The type of exception(s) that occurred. |
|
||||
| Exception message | `$exception_values` | The message(s) detected on the error. |
|
||||
| Exception function | `$exception_functions` | The function(s) where the exception occurred. |
|
||||
| Exception source | `$exception_sources` | The source file(s) where the exception occurred. |
|
||||
| Exception was handled | `$exception_handled` | Whether the exception was handled by the application. |
|
||||
| Device type | `$device_type` | The type of device that the error occurred on. |
|
||||
| Browser | `$browser` | The browser that the error occurred in. |
|
||||
| Current URL | `$current_url` | The URL that the error occurred on. |
|
||||
| Feature flag | `$feature_flag` | The feature flag that the error occurred on. |
|
||||
|
||||
You can also set custom properties on the error tracking event to filter on. For example, setting a custom `params_received` property to provide more context or debug information.
|
||||
|
||||
### Order of issue assignment rules
|
||||
|
||||
Issue assignment filters are evaluated in the order they are configured. They can also be reordered once created. The first filter that matches is used to assign the issue. This means you should configure the most specific filters first, and then the more general filters later.
|
||||
|
||||
### Alerting based on assignment
|
||||
|
||||
A common use case for automatic issue assignment is to alert assignees of new issues. Once the issues are automatically assigned, you can set up alerts to notify the assignee. See the [alerts](/docs/error-tracking/alerts) guide for more information.
|
||||
255
contents/docs/error-tracking/capture.mdx
Normal file
255
contents/docs/error-tracking/capture.mdx
Normal file
@@ -0,0 +1,255 @@
|
||||
---
|
||||
title: Capture exceptions for error tracking
|
||||
---
|
||||
|
||||
import Tab from "components/Tab"
|
||||
|
||||
You can track and monitor errors and exceptions in your code by capturing [exception events](/docs/error-tracking/issues-and-exceptions). This can be done automatically when exceptions are thrown in your code, or manually by calling the exception capture method.
|
||||
|
||||
## Capturing exceptions
|
||||
|
||||
Exceptions are a special type of [event](/docs/data/events) in PostHog. Similar to any other event, they can be captured, customized, filtered, and used in insights for analysis.
|
||||
|
||||
To help group exceptions into issues and help you debug them, PostHog automatically captures the following properties:
|
||||
|
||||
import ExceptionPropertiesTable from './_snippets/exception-properties-table.mdx'
|
||||
|
||||
<ExceptionPropertiesTable />
|
||||
|
||||
Like normal events, it's important to [identify the user](/docs/product-analytics/identify) when capturing exceptions.
|
||||
|
||||
import { CalloutBox } from 'components/Docs/CalloutBox'
|
||||
|
||||
<CalloutBox icon="IconInfo" title="Source maps" type="fyi">
|
||||
|
||||
If you serve minified or compiled code, PostHog needs source maps to display the correct stack traces. [Configure source maps](/docs/error-tracking/upload-source-maps) to get the most out of your exception events.
|
||||
|
||||
</CalloutBox>
|
||||
|
||||
### Automatic exception capture
|
||||
|
||||
If you followed one of our guides to [set up error tracking](/docs/error-tracking/installation) and you [enabled exception auto capture](https://app.posthog.com/error_tracking/configuration), you'll have automatic exception capture enabled.
|
||||
|
||||
```js
|
||||
posthog.init('<ph_project_api_key>', {
|
||||
api_host: '<ph_api_client_host>',
|
||||
defaults: '<ph_posthog_js_defaults>',
|
||||
capture_exceptions: {
|
||||
capture_unhandled_errors: true, // default
|
||||
capture_unhandled_rejections: true, // default
|
||||
capture_console_errors: false // default
|
||||
}
|
||||
})
|
||||
```
|
||||
|
||||
### Manual exception capture
|
||||
|
||||
You can also manually call the exception capture method.
|
||||
|
||||
<MultiLanguage>
|
||||
|
||||
```javascript file=Web
|
||||
posthog.captureException(error, {
|
||||
custom_property: "custom_value",
|
||||
custom_list: ["custom_value_1", "custom_value_2"],
|
||||
})
|
||||
```
|
||||
|
||||
```javascript file=Node.js
|
||||
posthog.captureException(e, 'user_distinct_id', {
|
||||
custom_property: "custom_value",
|
||||
custom_list: ["custom_value_1", "custom_value_2"],
|
||||
})
|
||||
```
|
||||
|
||||
```python
|
||||
additional_properties = {
|
||||
"custom_property": "custom_value",
|
||||
"custom_list": ["custom_value_1", "custom_value_2"],
|
||||
}
|
||||
|
||||
posthog.capture_exception(
|
||||
e,
|
||||
distinct_id="user_distinct_id",
|
||||
properties=additional_properties
|
||||
)
|
||||
```
|
||||
|
||||
</MultiLanguage>
|
||||
|
||||
## Customizing exception capture
|
||||
|
||||
Like all data, the better **quality** of your exception events, the more **context** you'll have for debugging and analysis. Customizing exception capture helps you do this.
|
||||
|
||||
Customizing exception capture lets you override exception properties to influence how they're grouped into issues.
|
||||
|
||||
Equally important, you can customize properties on the exceptions to help you configure rules for [automatic issue assignment](/docs/error-tracking/assigning-issues#automatic-issue-assignment), [alerts](/docs/error-tracking/alerts), [issue grouping](/docs/error-tracking/grouping-issues). They can also be used in analysis in [insights](/docs/product-analytics/insights), [dashboards](/docs/product-analytics/dashboards), and [data warehouse queries](/docs/product-analytics/data-warehouse).
|
||||
|
||||
### Customizing exception properties
|
||||
|
||||
#### During manual capture
|
||||
|
||||
When capturing exceptions manually, passing properties to the capture exception method adds them to the event just like any other PostHog event.
|
||||
|
||||
You can also override the [fingerprint](/docs/error-tracking/fingerprints) to [group](/docs/error-tracking/issues-and-exceptions#how-are-issues-grouped) exceptions together at capture time.
|
||||
|
||||
Here are some examples of how to override exception properties:
|
||||
|
||||
<MultiLanguage>
|
||||
|
||||
```javascript file=Web
|
||||
try {
|
||||
// ...
|
||||
} catch (error) {
|
||||
posthog.captureException(error, {
|
||||
"custom_property": "custom_value",
|
||||
// You can also *optionally* override generated properties like fingerprint
|
||||
"$exception_fingerprint": "CustomExceptionGroup",
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
```javascript file=Node.js
|
||||
try {
|
||||
// ...
|
||||
} catch (error) {
|
||||
posthog.captureException(error, 'user_123', {
|
||||
"custom_property": "custom_value",
|
||||
// You can also *optionally* override generated properties like fingerprint
|
||||
"$exception_fingerprint": "CustomExceptionGroup",
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
```python
|
||||
import posthog
|
||||
|
||||
posthog.api_key = '<ph_project_api_key>'
|
||||
posthog.host = '<ph_client_api_host>'
|
||||
|
||||
# With context
|
||||
with posthog.new_context():
|
||||
posthog.identify_context(distinct_id="user_123")
|
||||
|
||||
# When using context, you define properties with tags
|
||||
posthog.tag("custom_property", "custom_value")
|
||||
|
||||
# You can also *optionally* override generated properties like fingerprint
|
||||
posthog.tag("$exception_fingerprint", ["custom_fingerprint"])
|
||||
|
||||
posthog.capture_exception(Exception("Test custom exception"))
|
||||
|
||||
# Or without context
|
||||
posthog.capture_exception(
|
||||
Exception("Test custom exception without context"),
|
||||
distinct_id="user_123",
|
||||
properties={
|
||||
"$exception_type": "Custom exception without context",
|
||||
"$exception_fingerprint": ["custom_fingerprint without context"],
|
||||
"custom_property": "custom_value",
|
||||
},
|
||||
)
|
||||
```
|
||||
|
||||
</MultiLanguage>
|
||||
|
||||
#### During automatic capture
|
||||
|
||||
When automatic exception capture is enabled, you can still override the default properties and add custom properties to the exception event.
|
||||
|
||||
You can also override the [fingerprint](/docs/error-tracking/fingerprints) to [group](/docs/error-tracking/issues-and-exceptions#how-are-issues-grouped) exceptions together at capture time.
|
||||
|
||||
The process is slightly different depending on the SDK you're using.
|
||||
|
||||
<Tab.Group tabs={['Web and Node.js', 'Python']}>
|
||||
<Tab.List>
|
||||
<Tab>Web and Node.js</Tab>
|
||||
<Tab>Python</Tab>
|
||||
</Tab.List>
|
||||
<Tab.Panels>
|
||||
<Tab.Panel>
|
||||
|
||||
In [JavaScript Web](/docs/libraries/javascript) and [Node.js](/docs/libraries/node) SDKs, you can override the default properties by passing a `before_send` callback. This callback is called before any exception is captured.
|
||||
|
||||
```javascript
|
||||
posthog.init('<ph_project_api_key>', {
|
||||
api_host:'<ph_client_api_host>',
|
||||
defaults: '<ph_posthog_js_defaults>',
|
||||
before_send: (event) => {
|
||||
if (event && event.event === "$exception") {
|
||||
const exceptionList = event.properties?.["$exception_list"] || []
|
||||
const exception = exceptionList.length > 0 ? exceptionList[0] : null;
|
||||
|
||||
if (exception) {
|
||||
event.properties["custom_property"] = "custom_value"
|
||||
// You can also *optionally* override generated properties like fingerprint
|
||||
event.properties["$exception_fingerprint"] = "MyCustomGroup"
|
||||
// ... and any other properties you want to override
|
||||
}
|
||||
}
|
||||
return event
|
||||
}
|
||||
})
|
||||
```
|
||||
|
||||
</Tab.Panel>
|
||||
<Tab.Panel>
|
||||
|
||||
In Python, you can override the default properties through the use of [contexts](/docs/libraries/python#contexts) and tags.
|
||||
|
||||
```python
|
||||
import posthog
|
||||
|
||||
posthog.api_key = '<ph_project_api_key>'
|
||||
posthog.host = '<ph_client_api_host>'
|
||||
|
||||
# With context
|
||||
with posthog.new_context():
|
||||
posthog.identify_context(distinct_id="<user_distinct_id>")
|
||||
posthog.set_context_session(session_id="<session_id>")
|
||||
|
||||
posthog.tag("custom_property", "custom_value")
|
||||
# You can also *optionally* override generated properties like fingerprint
|
||||
posthog.tag("$exception_fingerprint", ["custom_fingerprint"])
|
||||
|
||||
# When this exception is automatically captured, it will be tagged with the custom properties
|
||||
raise Exception("Test custom exception")
|
||||
```
|
||||
|
||||
</Tab.Panel>
|
||||
</Tab.Panels>
|
||||
</Tab.Group>
|
||||
|
||||
### Capturing properties for custom issue grouping rules
|
||||
|
||||
Other than grouping with [custom fingerprints](#customizing-exception-properties), you can also set custom properties on the exception to help you group exceptions together using [issue grouping rules](/docs/error-tracking/grouping-issues).
|
||||
|
||||
For example:
|
||||
|
||||
- Setting fields like `db_transaction` to group exceptions together for a specific database transactions.
|
||||
- Setting `feature_name`, `service_name`, or `service_version` to group exceptions together for a specific features and services.
|
||||
- Setting `intent` to group exceptions due to common interactions like accessing storage or network.
|
||||
|
||||
It's important to think about your grouping rules when you configure exception capture. You cannot group exceptions together if you don't set some common properties between them.
|
||||
|
||||
Note that grouping issues means that all exceptions will be grouped together under a **single issue**. You **cannot** group exceptions into multiple issues, but you can still [filter on custom properties](/docs/error-tracking/monitoring#finding-specific-issues) across multiple issues without grouping them.
|
||||
|
||||
## Suppressing exceptions
|
||||
|
||||
We recommend that you suppress exceptions on the client side for performance and cost reasons.
|
||||
|
||||
import BeforeSendHook from './_snippets/before-send-hook.mdx'
|
||||
|
||||
<BeforeSendHook />
|
||||
|
||||
You can also suppress exceptions in PostHog, these rules will be applied client-side.
|
||||
|
||||
import SuppressionRules from './_snippets/suppression-rules.mdx'
|
||||
|
||||
<SuppressionRules />
|
||||
|
||||
## Burst protection
|
||||
|
||||
import BurstProtection from './_snippets/burst-protection.mdx'
|
||||
|
||||
<BurstProtection />
|
||||
@@ -26,60 +26,27 @@ Alternatively, you can disable exception autocapture completely in your [project
|
||||
|
||||
### Suppression rules
|
||||
|
||||
Autocaptured exceptions can be ignored client-side by [configuring suppression rules](https://us.posthog.com/error_tracking/configuration?tab=error-tracking-exception-autocapture#selectedSetting=error-tracking-exception-autocapture). Because the stack of an exception may still be minified client-side, you can only filter based on the exception type and message attributes.
|
||||
import SuppressionRules from './_snippets/suppression-rules.mdx'
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/suppression_rule_light_8db44eb6b1.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/suppression_rule_dark_5972d57398.png"
|
||||
alt="Issue suppression rules"
|
||||
classes="rounded"
|
||||
/>
|
||||
<SuppressionRules />
|
||||
|
||||
### Burst protection
|
||||
|
||||
The PostHog JS SDK uses burst protection to limit the number of autocaptured exceptions that can be captured in a period. This prevents an excessive amount of exceptions being captured from any one client, typically because they're being thrown in an infinite loop.
|
||||
import BurstProtection from './_snippets/burst-protection.mdx'
|
||||
|
||||
By default, we capture 10 exceptions (bucket size) of the same type within a 10 second period before the rate limiter kicks in, after which, we capture 1 exception (refill rate) every 10 seconds.
|
||||
|
||||
Often not needed, but you can change the bucket size and refill rate can be changed as part of your configuration:
|
||||
|
||||
```
|
||||
error_tracking: {
|
||||
__exceptionRateLimiterRefillRate: 1
|
||||
__exceptionRateLimiterBucketSize: 10
|
||||
}
|
||||
```
|
||||
<BurstProtection />
|
||||
|
||||
### Using the `before_send` hook
|
||||
|
||||
The [`before_send`](/docs/libraries/js/features#amending-or-sampling-events) callback in the JS SDK will drop events if a falsey value is returned. You can provide a `before_send` function when initializing the PostHog client to exclude any exception events you do not wish to capture client-side.
|
||||
import BeforeSendHook from './_snippets/before-send-hook.mdx'
|
||||
|
||||
```js
|
||||
posthog.init('<ph_project_api_key>', {
|
||||
before_send: (event) => {
|
||||
if (event.event === "$exception") {
|
||||
const exceptionList = event.properties["$exception_list"] || []
|
||||
const exception = exceptionList.length > 0 ? exceptionList[0] : null;
|
||||
|
||||
if (exception && exception["$exception_type"] == "UnwantedError") {
|
||||
return false
|
||||
}
|
||||
}
|
||||
return event
|
||||
}
|
||||
})
|
||||
```
|
||||
<BeforeSendHook />
|
||||
|
||||
## Issue suppression
|
||||
|
||||
If the exceptions you do not wish to capture are all being grouped under the same issue, you can suppress them so that subsequent exception events will not be ingested. Issues can be suppressed from the list or issue page by changing their status to **Suppressed**.
|
||||
import IssueSuppression from './_snippets/issue-suppression.mdx'
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/suppress_issue_light_ef0e5156a9.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/suppress_issue_dark_dc96ef44b2.png"
|
||||
alt="Issue suppression status"
|
||||
classes="rounded"
|
||||
/>
|
||||
<IssueSuppression />
|
||||
|
||||
## Quota limiting
|
||||
|
||||
|
||||
51
contents/docs/error-tracking/external-tracking.mdx
Normal file
51
contents/docs/error-tracking/external-tracking.mdx
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: Track external issues in GitHub and Linear
|
||||
---
|
||||
|
||||
import Tab from "components/Tab"
|
||||
|
||||
Other than assigning issues to team members in PostHog, you can also create issues in other tracking systems you use like GitHub Issues or Linear.
|
||||
|
||||
> If you use another issue tracking system and would like to request it, [let us know in-app](https://app.posthog.com#panel=support%3Afeedback%3Aerror_tracking%3Alow%3Atrue).
|
||||
|
||||
## Setting up external tracking
|
||||
|
||||
You can set up external tracking in the [error tracking settings](https://app.posthog.com/project/configuration?tab=error-tracking-integrations). Click **Connect workspace** and follow the prompts to connect your issue tracking system.
|
||||
|
||||
<Tab.Group tabs={['GitHub', 'Linear']}>
|
||||
<Tab.List>
|
||||
<Tab>GitHub</Tab>
|
||||
<Tab>Linear</Tab>
|
||||
</Tab.List>
|
||||
<Tab.Panels>
|
||||
<Tab.Panel>
|
||||
|
||||
PostHog connects to GitHub by installing a GitHub application. PostHog needs the following permissions:
|
||||
|
||||
- Read access to metadata
|
||||
- Read and write access to code, issues, and pull requests
|
||||
|
||||
</Tab.Panel>
|
||||
<Tab.Panel>
|
||||
|
||||
PostHog connects to Linear using a [third-party app](https://linear.app/docs/third-party-application-approvals). PostHog needs the following permissions:
|
||||
|
||||
- Create issues for your workspace
|
||||
- Read access to your workspace
|
||||
|
||||
</Tab.Panel>
|
||||
</Tab.Panels>
|
||||
</Tab.Group>
|
||||
|
||||
## Creating external issues
|
||||
|
||||
Issues can be created from the issue page. In an issue's details page, under **External references**, click **+ Create issue**.
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/create_issue_error_light_b89cd91da1.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/create_issue_error_dark_7d158087f8.png"
|
||||
alt="Error tracking create issue in external tracking system"
|
||||
classes="rounded"
|
||||
/>
|
||||
|
||||
The new issue will have a partial stack trace and a link to the issue in PostHog.
|
||||
70
contents/docs/error-tracking/fingerprints.mdx
Normal file
70
contents/docs/error-tracking/fingerprints.mdx
Normal file
@@ -0,0 +1,70 @@
|
||||
---
|
||||
title: Fingerprints
|
||||
---
|
||||
|
||||
Every captured exception is assigned a fingerprint. This fingerprint is used to group similar exceptions into issues. This page covers how fingerprints are generated, how they're used, and how you can override them when capturing exceptions.
|
||||
|
||||
## Fingerprint and issue grouping
|
||||
|
||||
Every exception has a fingerprint, whether generated or defined by the user. Each fingerprint links to exactly one issue. Exceptions that share the same fingerprint define an issue.
|
||||
|
||||
Multiple different fingerprints can point to the same issue (a many-to-one relationship) if you [merge issues](/docs/error-tracking/managing-issues#merging-issues).
|
||||
|
||||
## How are fingerprints generated?
|
||||
|
||||
Fingerprints are built iteratively using components of the exception event. The flowchart below shows how fingerprints are generated.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Add exception type to fingerprint] --> B{Stack trace<br/>available?}
|
||||
|
||||
B -->|No| C[Add error message to fingerprint]
|
||||
|
||||
C --> D[Final fingerprint]
|
||||
|
||||
B -->|Yes| E{In-app frames<br/>exist?}
|
||||
|
||||
E -->|No| F[Add first frame to fingerprint]
|
||||
|
||||
E -->|Yes| G[Add in-app frame to fingerprint<br/>Priority: resolved > unresolved]
|
||||
|
||||
F --> D
|
||||
G --> D
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>The flowchart in text</summary>
|
||||
|
||||
Fingerprints are generated by considering the following in combination:
|
||||
|
||||
1. The exception type
|
||||
2. If there's no resolved stack trace, add the error message to the fingerprint
|
||||
3. If there are stack traces but no in-app frames (frames from your code, not a dependency), use the first frame of the stack trace
|
||||
4. If there are stack traces, in-app frames, and source maps available, use the resolved in-app stack frames
|
||||
5. If there are stack traces, in-app frames, and source maps *not* available, use the first in-app stack frame
|
||||
|
||||
</details>
|
||||
|
||||
In some languages, like Python, one error can trigger another, creating a chain of linked exceptions. PostHog records the entire chain in the event and generates a single fingerprint for it.
|
||||
|
||||
### Ensuring accurate fingerprints
|
||||
|
||||
[Resolved stack traces](/docs/error-tracking/stack-traces) are critical for accurate fingerprinting. Without accurate stack traces, PostHog cannot group exceptions consistently. If you have not uploaded source maps, follow the [source map guide](/docs/error-tracking/upload-source-maps) to do so.
|
||||
|
||||
This also means that if the exception **type** or **message** changes from one version to the next, the fingerprint will change.
|
||||
|
||||
## When are generated fingerprints used?
|
||||
|
||||
Fingerprints are used to group similar exceptions into issues automatically. Automatic issue grouping is only done when:
|
||||
|
||||
- No [issue grouping rules](/docs/error-tracking/grouping-issues) are applied
|
||||
- No [issue merging](/docs/error-tracking/managing-issues#merging-issues) has been configured
|
||||
- No [custom fingerprint](#customizing-fingerprints) is set during capture
|
||||
|
||||
You can find details about how issue grouping works in the [issues and exceptions](/docs/error-tracking/issues-and-exceptions) guide.
|
||||
|
||||
## Customizing fingerprints
|
||||
|
||||
Fingerprints can be manually set during exception capture. This is a very useful way to group exceptions that are not related to each other. You can find examples of how to do this in the [custom issue grouping](/docs/error-tracking/grouping-issues#option-2-client-side-fingerprint) section.
|
||||
|
||||
You can also learn more about grouping issues using rules in the [grouping issues](/docs/error-tracking/grouping-issues) guide.
|
||||
104
contents/docs/error-tracking/grouping-issues.mdx
Normal file
104
contents/docs/error-tracking/grouping-issues.mdx
Normal file
@@ -0,0 +1,104 @@
|
||||
---
|
||||
title: Grouping exceptions into issues
|
||||
---
|
||||
|
||||
import { CalloutBox } from 'components/Docs/CalloutBox'
|
||||
|
||||
Issues are created by grouping together similar exception events. When **no custom grouping behavior is configured**, exceptions are grouped together automatically based on their [fingerprint](/docs/error-tracking/fingerprints).
|
||||
|
||||
> We're working on improving our grouping algorithm. If you spot two issues that you think should have been one, or one issue that you think should have been split into two, please [let us know in-app](https://app.posthog.com#panel=support%3Afeedback%3Aerror_tracking%3Alow%3Atrue).
|
||||
|
||||
PostHog's default grouping logic may not work for every use case, making custom grouping a useful option. For example, you may want to group exceptions into issues by:
|
||||
|
||||
- Business logic, like all errors that occur at checkout
|
||||
- Specific service, like all error messages containing `postgres`
|
||||
- Specific feature, like all error messages containing `feature_flag_variant_a`
|
||||
|
||||
## Custom issue grouping
|
||||
|
||||
PostHog attempts to group similar exceptions into issues automatically. If you want more control over issue grouping, you can use custom grouping rules during ingestion or define a client-side fingerprint.
|
||||
|
||||
### Option 1: Custom grouping rule
|
||||
|
||||
You can group exceptions as a single issue based on their properties using custom grouping rules. As with [auto assignment rules](/docs/error-tracking/assigning-issues#automatic-issue-assignment), you have access to properties of the unminified stack trace because the rules run during ingestion.
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/custom_grouping_light_f3e99a56b5.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/custom_grouping_dark_927e7c5774.png"
|
||||
alt="Error tracking custom issue grouping"
|
||||
classes="rounded"
|
||||
/>
|
||||
|
||||
To create a **custom grouping rule** in the [error tracking settings](https://app.posthog.com/error_tracking/configuration?tab=error-tracking-custom-grouping#selectedSetting=error-tracking-custom-grouping):
|
||||
|
||||
1. Click the **Add rule** button to create a new grouping rule.
|
||||
2. Select **Any** to match any of the criteria, or **All** to match all of the criteria.
|
||||
3. Click the **+ Add filter** button to add a new filter. These filters can be configured to match any [event property](/docs/data/events) in PostHog.
|
||||
4. Click **Save** to create the rule.
|
||||
|
||||
Here are some common exception event properties you can filter on:
|
||||
|
||||
| Property | Event property | Description |
|
||||
| --- | --- | --- |
|
||||
| Exception type | `$exception_types` | The type of exception that occurred. |
|
||||
| Exception message | `$exception_values` | The message detected on the error. |
|
||||
| Exception source | `$exception_sources` | The source file(s) where the exception occurred. |
|
||||
| Exception level | `$exception_level` | The level of the severity of the error. |
|
||||
| Exception was handled | `$exception_handled` | Whether the exception was handled by the application. |
|
||||
|
||||
You can also set custom properties on the error tracking event to filter on. You can find more about custom properties on exception capture in the [capture guide](/docs/error-tracking/capture).
|
||||
|
||||
Grouping rules are evaluated in the order they are configured and can be reordered. The first rule that matches will be used to group exceptions into an issue. This means you should configure the most specific rules first, and then the more general rules. If you configure a catch-all rule first, it will always match and block other rules from being evaluated.
|
||||
|
||||
### Option 2: Client-side fingerprint
|
||||
|
||||
Every captured exception is assigned a [fingerprint](/docs/error-tracking/fingerprints) by PostHog during ingestion, which is used for grouping. You can override this by setting the `$exception_fingerprint` property when capturing exceptions.
|
||||
|
||||
```js
|
||||
posthog.captureException(error, { $exception_fingerprint: "MyCustomGroup" })
|
||||
```
|
||||
|
||||
If the exception is autocaptured, you need to modify the properties before the event is sent. The PostHog config offers a [`before_send`](/docs/libraries/js/features#amending-or-sampling-events) hook that fires for each event which you can use to alter event and add the property:
|
||||
|
||||
```javascript
|
||||
posthog.init("<ph_project_api_key>", {
|
||||
before_send: (event) => {
|
||||
if (event.event === "$exception") {
|
||||
const exceptionList = event.properties["$exception_list"] || []
|
||||
const exception = exceptionList.length > 0 ? exceptionList[0] : null;
|
||||
|
||||
if (exception && exception["$exception_type"] == "SyntaxError") {
|
||||
event.properties["$exception_fingerprint"] = "MyCustomGroup"
|
||||
}
|
||||
}
|
||||
return event
|
||||
}
|
||||
})
|
||||
```
|
||||
|
||||
## Issue grouping best practices
|
||||
|
||||
Exceptions can only be grouped under a single issue. Every issue is meant to represent a single problem that can be fixed by a single change. You should only group issues when the default grouping algorithm is creating a lot of noise.
|
||||
|
||||
Some examples of this could be:
|
||||
|
||||
- A common issue like `ClickHouseTimeout` that occurs in many different places, but are mistakenly labeled as different issues.
|
||||
- A specific error message that shouldn't account for any differences in stack traces, such as "Failed to send billing status to SQS for customer".
|
||||
|
||||
You should avoid using grouping to address problems that can be otherwise solved by [auto assignment rules](/docs/error-tracking/assigning-issues#automatic-issue-assignment) or filtering by [custom properties](/docs/error-tracking/capture#customizing-exception-properties). When you over-group issues, they lack specificity and become meaningless.
|
||||
|
||||
## How PostHog prioritizes issue grouping logic
|
||||
|
||||
PostHog prioritizes issue grouping logic in the following order:
|
||||
|
||||
1. Client-side defined custom fingerprint using `$exception_fingerprint`
|
||||
2. Match custom grouping rules defined in PostHog
|
||||
3. If no user defined logic, fall back to grouping as issues based on automatic fingerprinting
|
||||
|
||||
Read more about how PostHog prioritizes grouping logic in the [issues and exceptions guide](/docs/error-tracking/issues-and-exceptions#how-exceptions-are-grouped-into-issues).
|
||||
|
||||
## Merging separate issues
|
||||
|
||||
import MergingIssues from './_snippets/merging-issues.mdx'
|
||||
|
||||
<MergingIssues />
|
||||
105
contents/docs/error-tracking/issues-and-exceptions.mdx
Normal file
105
contents/docs/error-tracking/issues-and-exceptions.mdx
Normal file
@@ -0,0 +1,105 @@
|
||||
---
|
||||
title: Issues and exceptions
|
||||
---
|
||||
|
||||
This page introduces the concept of issues and exceptions, how they fit into the error tracking workflow, and how you can work with them.
|
||||
|
||||
## What is an exception?
|
||||
|
||||
Errors are initially captured as individual `$exception` events. Like other [events](/docs/data/events) in PostHog, they contain properties that you can use to filter and group them. You can also use them to create insights, filter recordings, trigger surveys, and more.
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/exception_activity_light_3fbe98b154.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/exception_activity_dark_57bf2554e0.png"
|
||||
alt="Exception events"
|
||||
classes="rounded"
|
||||
/>
|
||||
|
||||
<Caption>View recent exception events in the <strong>Activity</strong> tab</Caption>
|
||||
|
||||
You can expect the following properties to be present in the exception events (in addition to the [standard event properties](/docs/data/events#default-properties)):
|
||||
|
||||
import ExceptionPropertiesTable from './_snippets/exception-properties-table.mdx'
|
||||
|
||||
<ExceptionPropertiesTable />
|
||||
|
||||
These captured properties are used to build a [fingerprint](/docs/error-tracking/fingerprints) of the exception, which is used to group similar exceptions into issues.
|
||||
|
||||
## What is an issue?
|
||||
|
||||
Issues are groups of similar `$exception` events that share common event information, such as the exception type, message, and stack trace. They're the primary way you interact with captured exceptions in error tracking.
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/issues_list_light_0d64676348.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/issues_list_dark_b24ad6301b.png"
|
||||
alt="Issues list view"
|
||||
classes="rounded"
|
||||
/>
|
||||
<Caption>The error tracking dashboard displays a list of issues</Caption>
|
||||
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/issue_light_f17781d806.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/issue_dark_5e825b1fe6.png"
|
||||
alt="Issue view"
|
||||
classes="rounded"
|
||||
/>
|
||||
<Caption>Opening an issue shows detailed information about its exceptions</Caption>
|
||||
|
||||
When working in the context of error tracking, PostHog [groups similar exception events](/docs/error-tracking/grouping-issues) into issues to help you triage them and take action. You can do the following with issues:
|
||||
|
||||
- [Mark the issue as active, suppressed, or resolved](/docs/error-tracking/managing-issues#resolving-and-suppressing-issues)
|
||||
- [Assign the issue to a team member or role](/docs/error-tracking/assigning-issues)
|
||||
- [Connect the issue to an external tracking system like GitHub issues or Linear](/docs/error-tracking/external-tracking)
|
||||
- [View session replays to help root cause the issue](/docs/error-tracking/monitoring#viewing-session-replays)
|
||||
|
||||
## How exceptions are grouped into issues
|
||||
|
||||
PostHog attempts to group similar exceptions into an issue automatically by their exception type, exception message, and [stack traces](/docs/error-tracking/stack-traces). The quality of automatic grouping can vary depending on the data available.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
|
||||
I1["<strong>Issue #1 – TypeError </strong><br/> Status: Active<br/> Assigned: David<br/> Volume: 5.2K<br/> Message: #quot;Cannot read properties of undefined#quot;"]
|
||||
|
||||
I2["<strong>Issue #2 – ReferenceError </strong><br/> Status: Resolved<br/> Assigned: Olly<br/> Volume: 1.5K<br/> Message: #quot;userId is not defined at dashboard.js#quot;"]
|
||||
|
||||
I3["<strong>Issue #3 – NetworkError</strong><br/> Status: Suppressed<br/> Assigned: Hugues<br/> Volume: 3.9K<br/> Message: #quot;Failed to fetch from API endpoint#quot;"]
|
||||
|
||||
E1["<strong>Latest exception</strong><br/>service.py:1316<br/>21 hours ago"]
|
||||
|
||||
E2@{ shape: processes, label: "<strong>Grouped exceptions</strong><br/>service.py:1316<br/>5.2K events" }
|
||||
|
||||
E3@{ shape: processes, label: "<strong>Grouped exceptions</strong><br/>dashboard.js:15<br/>1.5K events" }
|
||||
|
||||
E4@{ shape: processes, label: "<strong>Grouped exceptions</strong><br/>main.go:248<br/>3.9K events" }
|
||||
|
||||
I1 --> E1
|
||||
I1 --> E2
|
||||
I2 --> E3
|
||||
I3 --> E4
|
||||
|
||||
```
|
||||
|
||||
You can customize issue grouping logic by using [custom grouping rules](/docs/error-tracking/grouping-issues#option-1-custom-grouping-rule), [merging issues](/docs/error-tracking/grouping-issues), or labeling exceptions with a [custom fingerprint](/docs/error-tracking/grouping-issues#option-2-client-side-fingerprint).
|
||||
|
||||
When multiple issue grouping methods apply, PostHog applies them in the following order:
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Exception Event] --> B{Custom fingerprint<br/>set?}
|
||||
B -->|Yes| C[Use custom fingerprint]
|
||||
B -->|No| D{Custom grouping rules<br/>match?}
|
||||
D -->|Yes| E[Use custom grouping rules]
|
||||
D -->|No| F[Use automatic fingerprinting]
|
||||
|
||||
C --> G[Create/update issue]
|
||||
E --> G
|
||||
F --> G
|
||||
```
|
||||
|
||||
1. Client-side defined [custom fingerprint](/docs/error-tracking/capture#customizing-exception-capture) using `$exception_fingerprint`
|
||||
2. Match [custom grouping rules](/docs/error-tracking/grouping-issues#option-2-custom-grouping-rule) defined in PostHog
|
||||
3. If no user defined logic, fall back to [automatic fingerprinting](/docs/error-tracking/fingerprints)
|
||||
|
||||
> We're working on improving our grouping algorithm. If you spot two issues that you think should have been one, or one issue that you think should have been split into two, please [let us know in-app](https://app.posthog.com#panel=support%3Afeedback%3Aerror_tracking%3Alow%3Atrue).
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
title: Issues
|
||||
---
|
||||
|
||||
## What is an issue?
|
||||
|
||||
Errors are captured as `$exception` events which means that you can create insights, filter recordings, trigger surveys, and more in the same way you can for any other type of event.
|
||||
|
||||
Exception events are grouped into **issues** based on event information, such as the exception type, message, and stack trace. The data used for grouping depends on what is available. This enables you to evaluate which issues are most important and prioritize work on fixing them.
|
||||
|
||||
We're working on improving our grouping algorithm. If you spot two issues that you think should have been one, or one issue that you think should have been split into two, please [let us know in-app](https://us.posthog.com#panel=support%3Afeedback%3Aerror_tracking%3Alow%3Atrue).
|
||||
|
||||
You can also manually combine two or more issues by [merging them](/docs/error-tracking/monitoring#merging-issues).
|
||||
|
||||
### Issue list
|
||||
|
||||
In addition to using events in insights, replays, and surveys as mentioned above customers can also visit the [error tracking page](https://us.posthog.com/error_tracking).
|
||||
|
||||
Exceptions are grouped by type, each with aggregated counts and sparklines providing an indication of the severity of each group.
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/Clean_Shot_2025_01_20_at_10_15_21_2x_f4848a78c6.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/Clean_Shot_2025_01_20_at_10_15_46_2x_f1f5e7f31b.png"
|
||||
alt="Error tracking overview"
|
||||
classes="rounded"
|
||||
/>
|
||||
|
||||
### Issue page
|
||||
|
||||
Clicking through to an individual group shows you all the associated exceptions, including the associated stack trace, active feature flags when the exception was captured, and a link to the relevant session replay.
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/issue_page_light_b74b913232.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/issue_page_dark_bfe4579559.png"
|
||||
alt="Error tracking issue page"
|
||||
classes="rounded"
|
||||
/>
|
||||
@@ -1,93 +1,66 @@
|
||||
---
|
||||
title: Issue management
|
||||
title: Manage and resolve issues
|
||||
---
|
||||
|
||||
Our error tracking product gives you multiple ways to help you manage issues and work towards resolution.
|
||||
|
||||
## Assigning issues
|
||||
## Update issue status
|
||||
|
||||
Issues can be assigned to a teammate from the list or issue page. To do this, select the **assignee** option and search for the teammate you want to assign it to, and select them. You can click this dropdown again to remove the assignee.
|
||||
You can update the status of an issue from the issue page under **Status** or issue list.
|
||||
|
||||
Want to assign issues to a **team** rather than an individual teammate? You can create a role in [your project settings](https://us.posthog.com/settings/organization-roles) under **Error tracking**.
|
||||
All issues are marked **Active** by default, you can mark them as **Resolved** or **Suppressed** to reflect the current state of the issue. These labels are mainly used to communicate amongst your team.
|
||||
|
||||
- Resolve issues that are fixed, if they reoccur, the issue is reopened.
|
||||
- Suppress issues that you choose not to action. Typically, this is used for issues that are deemed noisy or not helpful.
|
||||
|
||||
You can also filter issues by status in the issue list:
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/roles_light_6c7ea17be9.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/roles_dark_f721b94577.png"
|
||||
alt="Error tracking role assignees"
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/filter_by_status_light_1f57d7d0b1.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/filter_by_status_dark_f48d183989.png"
|
||||
alt="Error tracking filter by issue status"
|
||||
classes="rounded"
|
||||
/>
|
||||
|
||||
### Auto assignment rules
|
||||
A common workflow is to look for all issues that are **Active** assigned to you or your team, and triage them to be fixed or suppressed.
|
||||
|
||||
You can automatically assign new and reopened issues using [auto assignment rules](https://us.posthog.com/error_tracking/configuration?tab=error-tracking-auto-assignment#selectedSetting=error-tracking-auto-assignment).
|
||||
## View stack traces and event properties
|
||||
|
||||
Assignment conditions are evaluated against the properties of the exception event that created the issue. Because assignment rules are evaluated during ingestion, the stack trace (if present) will be unminified which allows for filtering on on exception properties such as function name and source file.
|
||||
Each issue contains detailed information about the exceptions that triggered it.
|
||||
|
||||
Click the **Stacktrace** tab to see exactly where the error occurred. [Stack traces](/docs/error-tracking/stack-traces) help you pinpoint the line of code and the sequence of function calls leading up to the exception.
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/assignment_rules_light_1cf9a2437a.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/assignment_rules_dark_11e0830b0c.png"
|
||||
alt="Error tracking auto assignment rules"
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/issues_stacktrace_light_8e0c699ca2.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/issues_stacktrace_dark_0b00f2d4fd.png"
|
||||
alt="Error tracking stack traces"
|
||||
classes="rounded"
|
||||
/>
|
||||
|
||||
Auto assignment works well when paired with [alerts filtered by assignee](/docs/error-tracking/alerts#alert-filtering).
|
||||
|
||||
## Merging issues
|
||||
|
||||
You can merge issues representing the same problem from the issue list by:
|
||||
|
||||
1. Selecting the primary issue others should be merged into
|
||||
2. Selecting the issue(s) to merge into the primary issue
|
||||
3. Clicking the **Merge** button
|
||||
|
||||
After merging, all events and properties from the merged issues are added to the primary issue. The merged issues are then deleted (but the underlying events are not).
|
||||
Under the **Properties** tab, you can view additional metadata about the exception event.
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/merge_light_0489da02c6.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/merge_dark_aab4bfcc93.png"
|
||||
alt="Error tracking issue merging"
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/issues_properties_light_6fa900f42e.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/issues_properties_dark_e973d3dfb2.png"
|
||||
alt="Error tracking event properties"
|
||||
classes="rounded"
|
||||
/>
|
||||
|
||||
## Custom issue grouping
|
||||
## Watch session replays
|
||||
|
||||
PostHog attempts to group the same exceptions as a single issue. If you want more control over issue grouping, you can define a grouping on the client-side or using rules during ingestion.
|
||||
Error tracking works with [session replays](/docs/session-replay) to help you understand the context of an issue. This is useful for reproducing and debugging issues.
|
||||
|
||||
### Client-side fingerprint
|
||||
|
||||
An `$exception_fingerprint` property is generated during ingestion by PostHog and used to perform this grouping. Setting the `$exception_fingerprint` property on the frontend will override the default flow to allow for custom grouping of certain exceptions.
|
||||
|
||||
When using the `captureException` method, you can provide `$exception_fingerprint` as an additional property in the functions second argument.
|
||||
|
||||
```js
|
||||
posthog.captureException(error, { $exception_fingerprint: "MyCustomGroup" })
|
||||
```
|
||||
|
||||
If the exception is autocaptured, you need to modify the properties before the event is sent. The PostHog config offers a [`before_send`](/docs/libraries/js/features#amending-or-sampling-events) hook that fires for each event which you can use to alter event and add the property:
|
||||
|
||||
```javascript
|
||||
posthog.init("<ph_project_api_key>", {
|
||||
before_send: (event) => {
|
||||
if (event.event === "$exception") {
|
||||
const exceptionList = event.properties["$exception_list"] || []
|
||||
const exception = exceptionList.length > 0 ? exceptionList[0] : null;
|
||||
|
||||
if (exception && exception["$exception_type"] == "SyntaxError") {
|
||||
event.properties["$exception_fingerprint"] = "MyCustomGroup"
|
||||
}
|
||||
}
|
||||
return event
|
||||
}
|
||||
})
|
||||
```
|
||||
|
||||
### Custom grouping rules
|
||||
|
||||
You can also choose to group exceptions as a single issue based on their properties. As with [auto assignment rules](#auto-assignment-rules), you have access to properties of the unminified stack trace because the rules run during ingestion.
|
||||
You can view a session replay for an exception by:
|
||||
- Selecting an exception in the exception list and clicking the **Session** tab at the top of the page.
|
||||
- Clicking the **View recording** button besides each exception.
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/custom_grouping_light_f3e99a56b5.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/custom_grouping_dark_927e7c5774.png"
|
||||
alt="Error tracking custom issue grouping"
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/session_replay_error_light_5f25f72344.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/issue_exception_with_filter_dark_bf74dca1d9.png"
|
||||
alt="An issue's session replay"
|
||||
classes="rounded"
|
||||
/>
|
||||
/>
|
||||
|
||||
## Assign issues to teammates
|
||||
|
||||
Issues can be [assigned to a teammate](/docs/error-tracking/assigning-issues) from the list or issue page. To do this, select the **assignee** option and search for the teammate you want to assign it to, and select them. You can click this dropdown again to remove the assignee.
|
||||
|
||||
@@ -1,12 +1,39 @@
|
||||
---
|
||||
title: Searching and monitoring issues
|
||||
title: Monitor and search issues
|
||||
---
|
||||
|
||||
This guide covers how to find the most relevant, urgent, and impactful issues in your error tracking using the [issues page](https://app.posthog.com/error_tracking).
|
||||
|
||||
## Monitoring issues
|
||||
|
||||
When you're monitoring issues in your project, there are generally two common workflows:
|
||||
|
||||
- You're exploring issues to identify impactful and problematic areas. You should use sorting features.
|
||||
- You're looking for issues assigned to you to resolve them. You should filter by the `Assigned to` property.
|
||||
|
||||
### Sorting issues
|
||||
|
||||
Issues can be sorted by the following properties:
|
||||
|
||||
| Property | Description |
|
||||
| --- | --- |
|
||||
| Last seen | The issue that has the most recent exception |
|
||||
| First seen | The issue that has the oldest exception |
|
||||
| Occurrences | The number of exceptions in the issue |
|
||||
| Users | The number of unique users affected by the issue |
|
||||
| Sessions | The number of unique sessions affected by the issue |
|
||||
|
||||
Sorting by **last seen** and **occurrences** are great ways to get a general sense of issues in your project. Sorting by **users** and **sessions** is great to find the most impactful issues if you're using other [filters](#finding-specific-issues) to narrow down your results.
|
||||
|
||||
### Monitoring issues assigned to you
|
||||
|
||||
You can filter issues by the **Assigned to** property to find issues assigned to you. This is especially useful if you configure [automatic issue assignment](/docs/error-tracking/assigning-issues) and configure [alerts](/docs/error-tracking/alerts) to notify you when new issues are created.
|
||||
|
||||
## Finding specific issues
|
||||
|
||||
You can use the search bar at the top of the [issue page](https://us.posthog.com/error_tracking) to filter issues based on the properties of the exceptions in that issue.
|
||||
You can use the search bar at the top of the [issue page](https://app.posthog.com/error_tracking) to filter issues based on the properties of the exceptions in that issue.
|
||||
|
||||
Search results are matched based on properties of exceptions grouped into the issues. For example, if you search for "TypeError", we show you all issues where *any* exception grouped into the issue has a type of "TypeError".
|
||||
Search results are matched based on [properties of exception events](/docs/error-tracking/issues-and-exceptions) grouped into the issues. For example, if you search for "TypeError", we show you all issues where *any* exception grouped into the issue has a type of "TypeError".
|
||||
|
||||
import { CalloutBox } from 'components/Docs/CalloutBox'
|
||||
|
||||
@@ -16,19 +43,20 @@ You may see seemingly unrelated issues in your search results because your searc
|
||||
|
||||
</CalloutBox>
|
||||
|
||||
### Filtering modes
|
||||
|
||||
The search bar provides two modes of filtering:
|
||||
|
||||
- Exact property filtering, which operates like property filters elsewhere in PostHog, enabling you to add terms like `where 'http_referer' is set` or `where 'library' equals 'web'`.
|
||||
|
||||
- [Freeform text search](#freeform-text-search), which does text matching for a subset of the error tracking specific properties of the exception event.
|
||||
#### 1. Exact property filtering
|
||||
|
||||
You add a property filter by clicking the property name shown here:
|
||||
This operates like property filters elsewhere in PostHog, enabling you to add terms like `where 'http_referer' is set` or `where 'library' equals 'web'`. You add a property filter by clicking the property name shown here:
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/adding_property_filter_1d7490b403.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/adding_property_filter_dark_dd03d08aa5.png"
|
||||
alt="Adding a property to the property filter"
|
||||
classes="rounded"
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/filtering_issues_light_2b2dd25208.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/filtering_issues_dark_17d1e67da6.png"
|
||||
alt="Adding a property to the property filter"
|
||||
classes="rounded"
|
||||
/>
|
||||
|
||||
Added property filters look like this:
|
||||
@@ -40,11 +68,12 @@ Added property filters look like this:
|
||||
classes="rounded"
|
||||
/>
|
||||
|
||||
The results of both of these filter types (property filters and freeform search) are ANDed together, such that only exceptions that match all filters are included in the search results.
|
||||
The results of both of these filter types (property filters and freeform search) are combined with `AND` logic, such that only exceptions that match all filters are included in the search results.
|
||||
|
||||
## Freeform text search
|
||||
#### 2. Freeform text search
|
||||
|
||||
The freeform search splits the text you give it into tokens. The search matches an exception if *each* of the tokens in your search term appear in one of the following:
|
||||
|
||||
This does text matching for a subset of the error tracking specific properties of the exception event. It splits the text you give it into tokens. The search matches an exception if *each* of the tokens in your search term appear in one of the following:
|
||||
- The exception type
|
||||
- The exception message
|
||||
- The function names in the exception stack trace (if known)
|
||||
@@ -79,28 +108,41 @@ Exception events can have more than one exception in them, due to language featu
|
||||
|
||||
For example, if you had a chained exception with the messages `MyCustomError: Failed to load user` and `Cannot read property 'age' of undefined`, searching for `cannot read property` would match the exception, because it matches *one* of the exception messages (`property` appears in the "root" one).
|
||||
|
||||
## Filtering exception occurrences within an issue
|
||||
## Issue details
|
||||
|
||||
Once you've found and opened the issue you want to investigate, you can use the same search interface to filter the exception list for a particular instance of the issue. This is particularly useful in cases where some exceptions in the issue have information others don't and you want to use that information for debugging.
|
||||
When you click on an issue, you'll see the details page of the issue.
|
||||
|
||||
Here's an example from our own systems. We select a recent occurrence of this issue to try and get more context on why it's happening, but the details available don't tell me much more than the stack trace:
|
||||
This page shows you the following:
|
||||
- The stack trace, properties, and sessions related to the **currently selected exception**.
|
||||
- Name, description, status, assignee, and external tracking links for the issue.
|
||||
- A filterable list of all exceptions in the issue. **Selecting an exception** will show you the stack trace, properties, and sessions related to that exception at the top of the page.
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/unfiltered_exception_list_8cdbf735c0.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/exception_list_unfiltered_dark_200b8be303.png"
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/issue_exception_no_filter_light_405a3332d7.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/issue_exception_no_filter_dark_dfce08c4b0.png"
|
||||
alt="An issue, with an unfiltered exception list"
|
||||
classes="rounded"
|
||||
/>
|
||||
|
||||
Here, we've added a property filter on `http_referer`, which we think will be useful for our debugging and can then easily select an occurrence where that property is set:
|
||||
### Filtering exception occurrences within an issue
|
||||
|
||||
Once you've found and opened the issue you want to investigate, you can use the same search interface to filter the exception list for a particular instance of the issue. This is particularly useful in cases where some exceptions in the issue have information others don't and you want to use that information for debugging.
|
||||
|
||||
For example, you can add a property filter on `http_referer` that shows all exceptions where the `http_referer` is set:
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/filtered_exception_list_7b51efa94f.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/exception_list_filtered_dark_70a70d9ce9.png"
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/issue_exception_with_filter_light_0fc6e1cb2d.png"
|
||||
imageDark="https://res.cloudinary.com/dmukukwp6/image/upload/issue_exception_with_filter_dark_bf74dca1d9.png"
|
||||
alt="An issue, with a filtered exception list"
|
||||
classes="rounded"
|
||||
/>
|
||||
|
||||
<CalloutBox icon="IconInfo" title="Alerts" type="info">
|
||||
|
||||
If you have a set of filters that you use often, you can create alerts for them. This way you can be notified when new issues match your filters. Learn more about [alerts](/docs/error-tracking/alerts).
|
||||
|
||||
</CalloutBox>
|
||||
|
||||
## Improving search performance
|
||||
|
||||
We try to return results to you within a second, but sometimes if you're querying over large amounts of data, it may take longer. The following can improve the search performance:
|
||||
@@ -109,4 +151,8 @@ We try to return results to you within a second, but sometimes if you're queryin
|
||||
|
||||
- **Use freeform search rather than property filters:** Our freeform searches are generally faster than property filters, as the total amount of data processed is smaller.
|
||||
|
||||
If you find your queries timing out or taking more than 30 seconds, please [let us know in-app](https://us.posthog.com/#panel=support%3Afeedback%3Aerror_tracking%3Alow%3Atrue)! We're always looking for benchmarks to improve against.
|
||||
If you find your queries timing out or taking more than 30 seconds, please [let us know in-app](https://app.posthog.com/#panel=support%3Afeedback%3Aerror_tracking%3Alow%3Atrue)! We're always looking for benchmarks to improve against.
|
||||
|
||||
## Suppressing issues
|
||||
|
||||
If you find issues that are not useful to you, you can suppress them by changing the status to **Suppressed**. We recommend that you also implement [client-side suppression](/docs/error-tracking/capture#suppressing-exceptions) to not capture these exceptions in the first place, for cost and performance reasons.
|
||||
@@ -6,7 +6,7 @@ import Tab from "components/Tab"
|
||||
|
||||
Error tracking enables you to view the stack trace and code context associated with an exception. This can help understand, identify and resolve the root cause of an issue.
|
||||
|
||||
For languages like Python, the stack trace and code context can be gathered by the PostHog client and requires no additional processing.
|
||||
Stack traces are available for all languages and can be found in the details page of an issue.
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/Screenshot_2025_01_30_at_09_48_09_63dd3c5241.png"
|
||||
@@ -15,13 +15,27 @@ For languages like Python, the stack trace and code context can be gathered by t
|
||||
classes="rounded"
|
||||
/>
|
||||
|
||||
## Symbol sets
|
||||
## Resolving stack traces
|
||||
|
||||
If you use a compiled language or server minified bundles, you'll need to [upload source maps](/docs/error-tracking/upload-source-maps) to get stack traces. Compiled or minified code obfuscates the original source code, so PostHog uses the source map to resolve the stack trace to the original source code.
|
||||
|
||||
For languages like Python, the stack trace and code context can be gathered by the PostHog client and requires no additional processing.
|
||||
|
||||
### Uploading source maps
|
||||
|
||||
If your source maps are not publicly hosted, you will need to upload them during your build process to see unminified code in your stack traces. You can either use the `@posthog/nextjs-config` package or the `posthog-cli` to handle this process. Select your platform to view instructions.
|
||||
|
||||
import UploadSourceMapPlatforms from './upload-source-maps/_snippets/upload-source-map-platforms.tsx'
|
||||
|
||||
<UploadSourceMapPlatforms />
|
||||
|
||||
## Troubleshooting symbol sets
|
||||
|
||||
Compiled or minified languages requires additional information to perform a process called symbolification to produce the same stack trace and code context output shown above. The additional information is known as a symbol set.
|
||||
|
||||
The `source` of a frame in the exception stack trace should point to the minified code of your application which should contain the `sourceMappingUrl` parameter denoting the location of the source map. These files must either be publicly accessible for PostHog to fetch or uploaded manually to symbolify the stack trace.
|
||||
|
||||
You can see the symbol sets fetched by PostHog and the associated frames within the [error tracking settings](https://us.posthog.com/settings/project-error-tracking#error-tracking-symbol-sets). Any missing symbol sets will also be present along with the failure reason. From here, you can also manually upload missing symbol sets or replace existing ones.
|
||||
You can see the symbol sets fetched by PostHog and the associated frames within the [error tracking settings](https://app.posthog.com/settings/project-error-tracking#error-tracking-symbol-sets). Any missing symbol sets will also be present along with the failure reason. From here, you can also manually upload missing symbol sets or replace existing ones.
|
||||
|
||||
<ProductScreenshot
|
||||
imageLight="https://res.cloudinary.com/dmukukwp6/image/upload/Screenshot_2025_01_29_at_21_24_09_7b244773eb.png"
|
||||
@@ -30,11 +44,4 @@ You can see the symbol sets fetched by PostHog and the associated frames within
|
||||
classes="rounded"
|
||||
/>
|
||||
|
||||
|
||||
import UploadSourceMapPlatforms from './upload-source-maps/_snippets/upload-source-map-platforms.tsx'
|
||||
|
||||
## Uploading source maps
|
||||
|
||||
If your source maps are not publicly hosted, you will need to upload them during your build process to see unminified code in your stack traces. You can either use the `@posthog/nextjs-config` package or the `posthog-cli` to handle this process. Select your platform to view instructions.
|
||||
|
||||
<UploadSourceMapPlatforms />
|
||||
We strongly recommend you follow the [upload source maps](/docs/error-tracking/upload-source-maps) guide to ensure your stack traces are uploaded automatically in CI instead of manually debugging the process. If you're still having issues, [let us know in-app](https://us.posthog.com/project/2#panel=support%3Afeedback%3Aerror_tracking%3A%3Afalse).
|
||||
@@ -3716,38 +3716,79 @@ export const docsMenu = {
|
||||
name: 'Concepts',
|
||||
},
|
||||
{
|
||||
name: 'Issues',
|
||||
url: '/docs/error-tracking/issues',
|
||||
name: 'Issues and exceptions',
|
||||
url: '/docs/error-tracking/issues-and-exceptions',
|
||||
icon: 'IconWarning',
|
||||
color: 'yellow',
|
||||
featured: true,
|
||||
},
|
||||
{
|
||||
name: 'Stack traces',
|
||||
url: '/docs/error-tracking/stack-traces',
|
||||
icon: 'IconCode',
|
||||
color: 'purple',
|
||||
featured: true,
|
||||
},
|
||||
{
|
||||
name: 'Fingerprints',
|
||||
url: '/docs/error-tracking/fingerprints',
|
||||
icon: 'IconBrackets',
|
||||
color: 'blue',
|
||||
},
|
||||
{
|
||||
name: 'Guides',
|
||||
},
|
||||
{
|
||||
name: 'Monitor issues',
|
||||
url: '/docs/error-tracking/monitoring',
|
||||
icon: 'IconGraph',
|
||||
color: 'orange',
|
||||
name: 'Capture exceptions',
|
||||
url: '/docs/error-tracking/capture',
|
||||
icon: 'IconLaptop',
|
||||
color: 'green',
|
||||
featured: true,
|
||||
},
|
||||
{
|
||||
name: 'Manage issues',
|
||||
name: 'Manage and resolve issues',
|
||||
url: '/docs/error-tracking/managing-issues',
|
||||
icon: 'IconWrench',
|
||||
color: 'green',
|
||||
icon: 'IconDashboard',
|
||||
color: 'purple',
|
||||
featured: true,
|
||||
},
|
||||
{
|
||||
name: 'Set up alerts',
|
||||
name: 'Assign issues to teammates',
|
||||
url: '/docs/error-tracking/assigning-issues',
|
||||
icon: 'IconUser',
|
||||
color: 'blue',
|
||||
featured: true,
|
||||
children: [
|
||||
{
|
||||
name: 'Overview',
|
||||
url: '/docs/error-tracking/assigning-issues',
|
||||
},
|
||||
{
|
||||
name: 'Track in GitHub and Linear',
|
||||
url: '/docs/error-tracking/external-tracking',
|
||||
},
|
||||
],
|
||||
},
|
||||
{
|
||||
name: 'Group exceptions into issues',
|
||||
url: '/docs/error-tracking/grouping-issues',
|
||||
icon: 'IconList',
|
||||
color: 'yellow',
|
||||
featured: true,
|
||||
},
|
||||
{
|
||||
name: 'Monitor and search issues',
|
||||
url: '/docs/error-tracking/monitoring',
|
||||
icon: 'IconSearch',
|
||||
color: 'seagreen',
|
||||
featured: true,
|
||||
},
|
||||
{
|
||||
name: 'Send alerts',
|
||||
url: '/docs/error-tracking/alerts',
|
||||
icon: 'IconBell',
|
||||
color: 'red',
|
||||
featured: true,
|
||||
},
|
||||
{
|
||||
name: 'Resources',
|
||||
@@ -3757,6 +3798,14 @@ export const docsMenu = {
|
||||
url: '/docs/error-tracking/cutting-costs',
|
||||
icon: 'IconPiggyBank',
|
||||
color: 'salmon',
|
||||
featured: true,
|
||||
},
|
||||
{
|
||||
name: 'More tutorials',
|
||||
url: '/docs/error-tracking/tutorials',
|
||||
icon: 'IconGraduationCap',
|
||||
color: 'blue',
|
||||
featured: true,
|
||||
},
|
||||
{
|
||||
name: 'Troubleshooting and FAQs',
|
||||
|
||||
@@ -1536,6 +1536,10 @@
|
||||
{
|
||||
"source": "/teams/cs-onboarding",
|
||||
"destination": "/teams/customer-success"
|
||||
},
|
||||
{
|
||||
"source": "/docs/error-tracking/issues",
|
||||
"destination": "/docs/error-tracking/issues-and-exceptions"
|
||||
}
|
||||
],
|
||||
"headers": [
|
||||
|
||||
Reference in New Issue
Block a user