The v11 rollout reduced visible errors while checkout failures kept reaching customers.
The customer needs complete checkout evidence, and its existing OpenTelemetry pipeline must not produce duplicate spans.
Who you’d be doing this for
“I got asked why checkout was failing, and the issue list looked quieter than ever.”
Daudi Tsegaye · Staff Application Engineer
Owns the customer’s React checkout flow and joins the on-call rotation when payment failures reach the support desk.
What is at stake
Checkout failures are reaching the customer’s support desk while some services send duplicate spans and others send no traces. You must weigh fast instrumentation changes against the risk of distorting the customer’s existing OpenTelemetry signal.
Why it isn’t already fixed
Every obvious fix costs something else. That’s the part you’d have to decide.
- fast release recovery vs. trustworthy telemetry
- OpenTelemetry continuity vs. duplicate spans
- standard SDK guidance vs. customer-specific architecture
- technical correction vs. durable developer adoption
Why Sentry
JavaScript SDK instrumentation determines whether developers can use application telemetry to diagnose failures in React applications.
Written with these in mind
Not your kind of problem? 20 more at Sentry, or browse every organization.
This is the setup. The work is inside.
Running it puts you in the room: the full situation and its constraints, stakeholders who push back in their own words, and the decisions that are yours to make. What you produce becomes a Day One Plan — work you can show someone instead of describing.