Sentry for FDEs: fixing bugs on a client site you are not at
You have no SSH access, no logs, and a client who just writes "it's broken". Sentry tells you what failed, where, and in which release.
In brief
- Sentry uses fingerprints to group similar events into a single issue, so you can see at once which error happens most
- Breadcrumbs show what the user just did, tags show which group the error falls into, and releases show which deploy caused it
- Before adding Sentry to a client's system, plan for scrubbing sensitive data, enabling tracing and the limits of the self-hosted version
- 1An error event occursBy default the SDK sends every error, because the error sample rate is 1
- 2Grouped into an issueSimilar events are grouped by fingerprint, which reveals how often the problem occurs
- 3Stack trace and breadcrumbsShow the failing line of code and the sequence of events just before it
- 4Filter by tagTags are indexed, so you can filter by browser, device or user
- 5Match against the releaseSuggests the commit that caused the error and flags a regression when an old bug returns
Each layer of context Sentry attaches narrows the question: what failed, on which line, for which users, from which deploy.
Graphic: FDE Times
Picture this: it is 10pm and the client messages you. “The order approval screen has gone blank again.” You cannot get into their server, and you do not know which users are affected or since when. How fast you fix it depends mostly on whether you have enough context. The complexity of the code is rarely what decides it.
For a Forward Deployed Engineer this is a familiar situation. The application you built runs in someone else’s environment, errors happen when you are not around, and the person reporting them is usually not an engineer. Sentry is the tool that brings that context back to your desk.
What does Sentry do beyond catching exceptions?
Sentry started as an open-source project. Today the company describes its mission as helping every developer diagnose, fix and optimise the performance of their code. The key word is “diagnose”: catching an error is only the first step. The real value lies in how Sentry organises errors.
The basic unit is the event, a single occurrence of an error. Left alone, 500 events are 500 lines that tell you nothing. Sentry uses fingerprints to group similar events into issues, so you can see how many times a problem has recurred and decide which error to tackle first.
Every issue has an Issue Details page. The Stack Trace section shows the line of code where the event failed. Breadcrumbs record the sequence of events leading up to the error, and because they are structured data they carry more information than traditional logs.
Three kinds of context, three different uses
Newcomers often confuse tags with context. On a client site, getting this wrong means that when you need to filter, you cannot. The table below summarises the difference:
| Data type | What it is | Use it when |
|---|---|---|
| Tag | A string key/value pair, indexed and searchable | You need to filter: which browser, device or user does this error affect? |
| Context | A group of related data to support debugging, not searchable | You need to read the details once you have opened a specific event |
| Breadcrumbs | A timeline of events before the error | You need to know what the user or system did just before it broke |
The rule that follows is simple. Anything you will want to ask about in the form “how many errors belong to group X” goes in a tag. Anything you only need to see while examining a specific case stays in context.
With the JavaScript SDK, a minimal configuration for the order approval app might look like this (the release name and values are illustrative):
Sentry.init({
dsn: "<DSN của project>",
release: "duyet-don@2.4.1",
sampleRate: 1.0,
});
// Tag: sẽ cần lọc theo chi nhánh
Sentry.setTag("branch_id", "cn-moi-07");
// Context: chỉ đọc khi mở một event cụ thể
Sentry.setContext("order", { orderId: "DH-1024", status: "pending" });The comments read, in English, “Tag: will need to filter by branch” and “Context: only read when opening a specific event”. The branch ID is a tag because sooner or later you will ask “does this error only happen at one branch?”. The order ID and order status sit in context because they are only useful when you are examining one event. The release line is what you will need at the end of the case below.
A worked case: the blank order approval screen
Back to the 10pm message. Suppose the app had Sentry installed from the start. You open the dashboard and see a new issue with a few hundred events: a few hundred blank screens that the fingerprint has grouped into one problem. This is one recurring error, not hundreds of different ones.
The stack trace points to a line that reads a field in the order data. The breadcrumbs show that just before the failure the user opened a filter and then called the API that fetches the order list. You filter by the branch_id tag and see the error only appears for one group of users, say those at a branch that was just added to the system.
The last piece is the release. In Sentry, a release is a version of code deployed to an environment. With releases in place, Sentry can suggest the commit, and the person, likely to have caused the error.
If this issue had been resolved before and now reappears in a new release, Sentry marks it as a regression. From that alone you know that this afternoon’s deploy brought an old bug back.
Before the client has even sent another screenshot, you can answer: what failed, on which line, for which users, from which release. The first thing to do is tell the client how far the impact reaches, then fix it. Clients usually need to hear “only the new branch is affected” sooner than they need the patch.
Where things go wrong on a client’s system
The biggest risk is data. The richer your breadcrumbs and context, the more likely they are to pull in end users’ email addresses, phone numbers or tokens. Sentry can scrub sensitive information on the server side just before storing it. For an app running inside a client’s system, configure this before you turn Sentry on in production, not afterwards.
The second trap is sampling. By default the SDK sends every error, because the error sample rate is 1. Transactions and tracing, however, are not sent unless you configure them. So when a client complains that something is “slow” rather than “broken”, a default installation gives you no performance data at all.
The third trap appears when the client requires on-prem hosting. Sentry has a self-hosted version, but it is only a minimal setup, with no guarantees and no dedicated support team. If you go this way, agree clearly with the client who will run and upgrade it, and do not assume it will be you.
Sentry also offers Seer, an AI debugging agent that scans incoming issues to find root causes and automate triage. Seer helps when issue volumes are high, but it can only work with the context you have sent. Without tags and releases, any agent is left guessing.
What to learn first, and how to test yourself
A sensible order is: become fluent at reading the Issue Details page, then attach a release to every deploy, then design a tag set for your domain, and only then move on to data scrubbing and tracing. Each step can be tried on a side project in an evening.
Self-test: for the order approval app above, decide whether each of these five fields belongs in a tag or in context: the user’s role (staff or manager), the browser, the list of products in the order, the environment (staging or production), and the response body of the API that fetches the order list.
Suggested answer: user role, browser and environment are tags, because you will want to ask “does this error only hit managers, only one browser, only production?”.
The product list and the API response are context, because they are only useful when examining one event. These two fields are also where sensitive data most easily slips in, so they must go through data scrubbing.
Once you have done this on a side project, put it on your CV exactly as you did it. A line such as “designed the tag set, release tracking and PII scrubbing for the app’s error monitoring” carries far more weight than “familiar with Sentry”.
On a client site, after go-live, the next time the client thinks of you is usually when something breaks. Whether you can answer straight away what failed, where and in which release, or have to wait for more screenshots, depends largely on how you configured Sentry on deployment day.