Getting Started with Error Tracking

Overview

This guide introduces AppStatus Error Tracking and covers:

• Automatic exception capture from your application SDK
• Grouping by stack shape, so one fault is one issue
• Release attribution — which deploy introduced it
• A plain-language explanation with a suggested fix
• Triage workflow: assign, resolve, and catch regressions

What is Error Tracking in AppStatus?

Every exception your services raise is fingerprinted by the shape of its stack trace. The same fault raised a thousand times becomes one issue with a count of a thousand, instead of a thousand separate rows to read.

Each issue carries its first and last occurrence, the services affected, the trace that produced it, and an explanation of what went wrong written in plain language, with a stated confidence level and a suggested fix.

Key capabilities:

• Server-side grouping — the same error groups identically regardless of which client reported it
• Release and environment attribution on every issue
• One-click path from an issue to the trace, logs and deploy around it
• Regression detection — a resolved issue that returns re-opens visibly
• Feedback control on every explanation, changeable at any time

What you will see

What the issue list looks like

Scroll the table sideways to see every column.

Troubleshooting

Operational Guidance

• Sort by users affected, not raw count — one loud background job can outrank a checkout failure.
• A resolved issue that reappears is a regression; treat it as new work, not noise.
• The explanation is a starting point with a stated confidence level — always confirm against the trace before shipping a fix.
• Rate the explanation with the thumbs control; that feedback is per user and can be changed.

Step-by-Step Setup

Error tracking needs one key and one SDK. After that, exceptions are captured without you wrapping anything by hand, and the work becomes triage rather than collection.

1. 1

   Create an ingest key scoped to errors

   Open Ingest Keys and create a key scoped to errors for the environment you are setting up. The key value is shown once — copy it into your secret manager now, not into source control.

   WhereIngest Keys → Create key

   Tip

   One scope per key. A key reused across signals turns a single leak into full ingest access.

2. 2

   Install the SDK

   Add the SDK for your language. Unhandled exceptions are captured automatically once it is initialised; you only call it explicitly for errors you catch and want reported anyway.

   WhereError Tracking → Add service
3. 3

   Set the release on every deploy

   Pass your commit SHA or build number as the release. This is what attributes an issue to the deploy that introduced it, and what makes a regression obvious later.

   WhereSDK configuration / CI environment variable

   Tip

   Skip this and you can still see errors — you just cannot tell which change caused them.

4. 4

   Trigger a test error

   Raise an exception deliberately and confirm it appears as an issue with the right service, environment and release attached.

   WhereError Tracking → Issues
5. 5

   Assign owners

   Set the owning team per service so new issues route to whoever can fix them, instead of arriving in a shared list nobody feels responsible for.

   WhereInsights → Service ownership

Configuration Options

Every option you can set, what each choice means, and what to pick. Use this as a reference while you fill in the form.

Feature Reference

Every feature, where to find it in the app, and what it does. Use this when you know what you want to do but not where it lives.

Next Steps

Continue building your monitoring stack: