Project observability-production-error-visibility-project · revised 11 October 2026
Project
Make one service's production errors visible, traceable and alerting
One service gets error tracking, structured logs with a request ID and two named alerts, proven together by a test failure you can follow from an alert to the error to the log lines of that request.
This asks for a proposal by email. Nothing is charged, and nothing starts, until you have agreed the scope, the price and the terms in writing.
The result you are buying
Errors in one service surface only when a customer complains. When the team does look, the error tracker, if there is one, and the logs cannot be connected, so nobody can go from an alert to the failing request. The project joins error capture, request-level logs and two named alerts into a single traceable path for one service.
Who it’s for: A founder or engineering lead whose service fails in ways the team hears about from customers, and who wants to see errors, trace one request and be told, as one piece of work.
Usually starts when: An outage or a run of customer reports showed that the team could not see the errors, could not follow one request through the logs and was not told by anything.
The result: A test failure in the non-production copy of the service fires the two agreed alerts, produces an error event with a readable stack trace and the request ID, and log lines carrying the same request ID, so one person can follow it from an alert to the cause. You accept the finished setup.
How the work fits together
The project is complete when both included outcomes have passed their own acceptance checks, the joined test failure has fired both alerts and been traced from an alert to the log lines, and you have accepted the finished setup.
Set up error tracking on one app and prove a test error reaches you readably Job Included
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.
Error capture with readable traces, release and environment, filtering and its own alert rule (alert 1, on new issues), as in the one-off job.
Structured logs with a request ID, and one alert, for one service Job Included
One service writes structured logs with a request ID on every line, with agreed secrets filtered, plus one alert on a failure condition you choose. A test request proves both.
Structured logs with a request ID and its own alert (alert 2, on an error-level line); it follows error tracking so the request ID can be attached to error events.
After: Error tracking set up on one app
Fix one reproducible bug with a failing-then-passing regression test Job Optional
One reproducible bug in one codebase: a regression test fails before the fix and passes after it. You get the repair pull request and both test results to review.
One bug at a time, if you ask
A defect that the first test failures reveal can be fixed as its own job.
How an engagement works
The price covers one service and the two agreed alerts. Further services, extra alerts and dashboards are quoted separately.
How it starts
You tell us about the service, how it is deployed, where its logs go and which tracker you use or prefer.
We check what is in place, propose the scope, the two alerts and the order of work, and quote a fixed price for the agreed service.
You agree the scope, price and terms in writing. Nothing starts before then.
We set up error tracking first, then structured logs and the alert, then join them and prove the whole path with a test failure.
We hand over the note, the field list and the settings summary, and you set the production values.
Who decides what
You own the accounts, decide who is notified, review and merge each pull request, and set the production values. We never touch production.
Handover
Everything arrives as pull requests and written notes in your own repository and tools. Tokens and accounts remain yours, and you can revoke our access at any time.
Sharing your product safely. Describe the service, its deployment and its tools in words, and send no code, tokens or log samples. After you agree the project, share the repository through an authorised company-controlled route and create a test-environment project in your tracker; tokens and project keys stay in your own secret store.
What is included, and what is not
- The pull requests for error tracking and for structured logging, merged in a sequence you approve
- The proof set: one test failure that fires both alerts, traced from the alert to the error event to the log lines that share its request ID
- A handover note that lets a person who did not build it follow the same path, and a field list of what is filtered
- A settings summary for the production values, which you set yourself
Included
- One service, one non-production copy for the proof and prepared production settings
- Error tracking connected with readable stack traces, release and environment, and sensitive fields filtered, with alert 1: a rule in the error tracker that notifies the destination you name when a new issue appears for the service
- Structured logs with a request ID on every line, with the same fields filtered, with alert 2: a rule in the log or monitoring tool you hold that notifies the destination you name when the service writes an error-level line. Alert 2 is a backstop for failures that never reach the tracker; one failure can fire both, and the settings summary says how to route or mute either
- The join between them: the request ID is attached to error events so an alert, the event and the log lines can be matched, and a short handover note that walks through that path
Not included
- Triaging or fixing the errors that arrive after setup; each is a separate job
- Dashboards, metrics, distributed tracing across several services or uptime checks
- More than one service, a mobile app, or a log platform or tracker account that you do not already hold or create
- Log retention, compliance requirements or a response time commitment for the alert
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
One deliberate test failure raised in the non-production copy fires both agreed alerts (the error tracker's new-issue alert and the log tool's error-line alert) and produces an error event with a readable stack trace, release and environment and the request ID, and log lines carrying the same request ID.
Evidence: The two notifications, the stored event and the log lines for that request, shown together with the request ID, and the alert used to start the traced path.
A person who did not build the setup follows only the handover note from the error tracker's alert to the log lines for that request and finds the failing line without help from us.
Evidence: That person's written account of the steps they took and anything they had to guess.
Invented secret-like and personal-looking values placed in the failing request appear in neither the error event nor the log lines.
Evidence: The stored event and the log output compared with the invented values and the field list.
Each included outcome has passed its own acceptance checks and the service still serves a normal request with the tracker's address blocked.
Evidence: The two components' acceptance records and the result of the blocked-tracker run.
Sign-off. You follow the path from the tracker's alert to the log lines yourself, check the filtered fields, and accept the finished setup in writing. You then set the production values.
If it fails. If a part cannot be completed, we name it with the reason and what it would take, and the price is adjusted to match what was done. Nothing is billed as delivered that you have not accepted.
When it fits, and when we stop
It fits when
- A non-production copy of the service exists where a test failure can be raised safely with invented data
- You own, or will create, the error-tracker account and hold a place where logs are read and alerts can be created
- You are allowed to send error data to the tracker you choose, and a named person can review and merge the pull requests
We stop and tell you if
- No safe non-production copy exists, so proof would mean raising errors in production
- Your policies do not allow sending error data to a third-party service
- Logging cannot be configured in one place and a safe change would touch most of the code: we propose a larger scope
What could go wrong
Each part is a separate pull request that your team merges, so any one can be reverted on its own. The tracker project and the alert are yours to delete. If the project stops, merged parts stay and the rest is handed back with notes.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Sensitive data reaches the tracker or the logs. | Both use the same agreed field list, filtered at the source, and acceptance includes invented secrets in the failing request that must appear in neither the event nor the log lines. |
| The request ID on error events and log lines does not match, so the trace breaks at the point where it is needed. | The joined test failure is the main acceptance check and it must be followed end to end by someone who did not build it. |
| The alerts are ignored or muted because they fire too often, or because one failure notifies twice. | Each of the two conditions is agreed and tested, both definitions are written down so you can tune or mute either, and the second is described as a backstop. Who responds is your decision. |
Each part is reviewed separately from the work that produced it, and a person who did not build the setup follows the handover note during acceptance. No human supervisor is included unless your proposal names one. At launch the work is largely automated, and we say so.
Stays with a person
- You approve the two alerts and their notification channels
- You review and merge each pull request and set the production values
Access we would need
- Read access to a repository or fork you control, a test-environment project in your tracker and read access to non-production logs; no production access
Questions
Why buy this instead of the two separate jobs?
The two jobs can each be bought alone. The project adds the join between them, the request ID on error events, and one proof that an alert can be followed to the failing request by someone who did not build it.
Which tracker and log tool do you use?
The ones you hold or choose, agreed before work. Say early which you use, so the proposal can confirm what we can set up.
Will this tell us about every outage?
No. It makes errors in the service visible and traceable and sends the two alerts you choose. Uptime checks, dashboards and response commitments are outside this scope.
Send an enquiry
Send us
- The service's language and framework in general terms, how it is deployed and where its logs go today
- The error tracker and the alerting or log tool you use or prefer, and where an alert should be sent
- Whether requests carry personal data or secrets that must never leave the service (yes or no, and a list of field names if you have one)
- Do not send code, tokens, log samples or customer data 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 requests
- A test-environment project created by you in your tracker, and read access to non-production logs through a route you approve. The tracker's build token and project key stay in your own secret store and are never sent to us; your pipeline runs the upload step and you raise the test failure and export the results
- The field names that must never leave the service, the destination for each of the two alerts and the person who accepts the finished setup
You own the service, the accounts, the tracker and log tools and every key. We work on a branch and a non-production copy through a company-controlled identity, never a personal login, with the narrowest access each tool offers. You review and merge every pull request and set the production values yourself.
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-production-error-visibility-project” as the subject.