Job observability-error-tracking-setup-for-one-app · revised 11 October 2026
Set up error tracking on one app and prove a test error reaches you readably
Error tracking is wired into one app with readable traces, release tags, filtered sensitive fields and one alert. Your build holds the tokens; we never receive them. A test error you raise proves it.
You might be seeing
- Production errors are found when a customer reports them, not when they happen
- An error tracker account exists but its stack traces are minified, its events lack a release, or nobody is notified
No passwords, keys, card details or admin invites needed to start.
What usually happened
Production errors go unnoticed because exceptions are not captured outside the server's own logs, or they are captured without what a person needs to act: minified stack traces, no release or environment, personal data in the payload and no rule that tells anybody. The job is capture, readability, payload safety and one alert path for a single application in a single environment. It does not triage or fix what arrives.
Who it’s for: A founder or engineering manager who learns about production errors from customers, or whose application logs errors that nobody reads.
Usually starts when: A customer reported a crash the team did not know about, or the team is about to launch and has no way to see production exceptions.
The result: A deliberate test error raised in the agreed non-production environment appears in your error tracker with a readable stack trace, the release and the environment, with sensitive fields filtered, and triggers a notification in the channel you chose. You receive the pull request that wires it in and a summary of the settings.
Check whether this job fits
Answer without sharing code, tokens or event data. These checks show whether one application can be connected and proven safely.
Checks you can run yourself
List what a request carries
Pick one typical request to your application and list the headers, form fields, query parameters and user fields it contains, using invented values. Mark any you would not want stored by a third party.
Look for: The marked items are the field list the filter must cover. A long list of personal fields is a reason to review the data-sharing question before enquiring.
What you get
- A pull request that wires the SDK in, sets the release and environment, and adds the build step for readable traces, reading the token and project key from your secret store by name only
- A settings summary: what is set, what was left at its default, and why, including the sampling and filtering choices and the exact settings of the one alert rule for you to create
- The proof set, exported or screenshotted from your tracker by you after you raise the test error: the test event with its readable trace, release and environment, the filtered fields and the notification it caused
- A short note on how to raise a test error again and what must never be put into an event
Included
- One application on one runtime, such as a Python or JavaScript web application, with one non-production environment to prove it in and the production configuration prepared for you to switch on
- Connect the tracker's SDK to capture unhandled exceptions, set the environment and release explicitly from your build or deploy so they match what you ship rather than relying on the SDK's automatic choice, and add the build step that uploads source maps or the equivalent where the shipped code is minified. Your own pipeline runs that step with a token kept in your secret store; the token and project key are never sent to us
- Review what an event carries and filter or drop sensitive fields before the event leaves the application, using the SDK's own hook, then confirm with an event that holds invented fake secrets
- Specify one alert rule for new issues that notifies the channel you name, with the filter you choose, as exact written settings that you create in your tracker; the deliberate test error must then trigger it
Not included
- Triaging or fixing the errors that arrive after setup; each is a separate job
- Performance monitoring, session replay, log aggregation or uptime checks
- Opening your tracker account or paying for a plan: you create and hold the account, projects and tokens
- More than one application, a mobile app or a second environment beyond the prepared production settings
- A promise that every error is captured: a process that crashes before it can send, blocked network paths and sampling can all drop events
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
A deliberate test error that you raise from a production-style build, made by your pipeline and deployed to the agreed non-production environment, appears in the tracker with a readable stack trace showing source file and line, and with the release and environment recorded.
Evidence: A screenshot or exported event of the test error, supplied by you, showing the trace, release and environment, and the release value used in the build.
A test event carrying invented secret-like and personal-looking values in the request and in an exception message arrives with every agreed sensitive field removed or masked.
Evidence: The raw event as stored in the tracker, exported by you, with the invented values and the agreed field list shown side by side.
The alert rule, created in your tracker from the settings we wrote, sends a notification to the named channel for the test error.
Evidence: A screenshot of the notification in the channel and of the rule's settings, supplied by you.
With the tracker's address blocked from the machine running the application, the application still serves a normal request and logs the failure to send instead of crashing.
Evidence: The request result and the application log from the blocked run.
The prepared production configuration is documented, no real token or key is in the repository, and your authorised maintainer accepts the pull request.
Evidence: The settings summary, the independently reviewed diff and your written sign-off.
Sign-off. You build and deploy the branch with your own token, raise the test error with the note we provide, check the event and the notification, send us the exports, sign off in writing and merge the pull request. You then set the production values. Payment follows sign-off.
If it fails. If the agreed checks do not pass, you do not pay for this fixed scope. If the build cannot produce readable traces or a safe test copy does not exist, we explain what would have to change and stop. Wider work needs a new written agreement.
When it fits, and when we stop
It fits when
- A staging, preview or local copy exists where a test error can be raised without affecting customers
- You own or will create an account with the error-tracking service, including its plan limits
- Your build can take a release value and an upload step, someone on your side can run that build with the upload token in the environment (in your pipeline or on a machine you control) and deploy it to the non-production environment, the code can be shared through an authorised company-controlled route after agreement, and a named person can review and merge the pull request
We stop and tell you if
- The application cannot run anywhere a test error can be raised safely, so the proof would have to happen in production
- Your policies do not allow sending error data to a third-party service
- The build cannot produce the information needed for readable traces and you do not want to change that: we agree in writing what readable means before going on
- The events would have to carry personal or regulated data that cannot be filtered at the source
What could go wrong
The change is one pull request. Closing it before merge changes nothing; after merge your maintainer can revert it, which removes the SDK and the build step. Revoking the build token and deleting the tracker project undo the account side, and those are yours.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Personal data or secrets are sent to a third party in event payloads. | Fields are filtered in the application before sending, the defaults are reviewed, and an event with invented fake values must arrive with them removed. We do not rely on server-side scrubbing alone. |
| A build token or project key leaks through us. | Neither is sent to us. They stay in your secret store, the pull request refers to them by name, and the reviewer checks that no real value appears in the diff or the proof set. |
| Alerts are noisy, so the team mutes the channel. | One alert rule with the filter you choose is specified, and the settings summary says how to narrow or widen it. |
| Stack traces stay unreadable because the uploaded maps do not match the code that is deployed. | The proof event comes from a production-style build with the same release value as the upload, and acceptance requires file and line to be readable. |
| The tracking code itself breaks the application when the tracker is unreachable. | Acceptance includes a run with the tracker's address blocked, where the application must still serve a normal request. |
An independent reviewer checks that no real data or token appears in the proof set, that the filter list matches the agreed fields and that the test event came from a built artefact, not a development server. Your authorised maintainer reviews and merges under your existing rules.
Need to keep it working?
Triage of the first errors that arrive, extra applications or keeping alert rules tuned over time are agreed in separate written scopes.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Sentry's documentation covers readable stack traces through source maps, including a wizard that sets up the upload; your maintainer can follow it without buying help. docs.sentry.io
- Sentry's Python documentation explains how to scrub data in the SDK before it is sent, which is the part most teams skip. docs.sentry.io
Questions
Which error tracker do you set up?
The one you hold or choose, agreed before work. The documentation we have read most closely is Sentry's, so say early if you use another service and we will confirm the scope.
Do you need our tokens or production keys?
No. The build token and project key stay in your own secret store and are never sent to us; the pull request refers to them by name and your pipeline runs the upload step. The proof runs in a non-production environment with a test project, and you set the production values yourself from the settings summary.
Will every error be captured?
No. A process that dies before it can send, a blocked network path and sampling can all drop events. The settings summary says what is and is not covered.
Will you fix the errors it finds?
No. Fixing one reproducible bug is a separate job with its own regression test.
Send an enquiry
Send us
- The application's language and framework in general terms, how it is built and deployed, and which error tracker you use or are considering
- Where notifications should go, such as a team channel or a mailbox
- Whether the application handles personal data in its requests (yes or no)
- Do not send code, tracker tokens, project keys or credentials in the first enquiry
Later, once you agree
- The agreed source revision through an authorised company-controlled code-export route, with a branch route for the pull request
- A test-environment project created by you in your tracker, and the narrowest build token the service allows for the source map upload, kept in your own CI secret store or build environment. We do not receive the token or the project key: the pull request refers to them by name, and your pipeline runs the upload step
- Your run of the build and deployment to the non-production environment, and your export or screenshots of the test events and notification for the proof set, using invented data only
- The notification channel, the field names that must never leave the application, and the person who accepts the setup
You own the application, the tracker account, its projects and tokens, and the notification channel. The build token and project key stay in your secret store and are never sent to us: we write the code that reads them by name, and you run the build and read the results in your own tracker. You set the production values yourself and merge the pull request.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “observability-error-tracking-setup-for-one-app” as the subject.