> For the complete documentation index, see [llms.txt](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/opentelemetry/from-missing-events-to-complete-visibility-tracing-enterprise-transactions-with-opentelemetry/day-5-34-auto-instrumentation-vs.-manual-instrumentation-its-all-about-trade-offs.md).
# Day 5/34 Auto Instrumentation vs. Manual Instrumentation — It’s All About Trade‑offs
OpenTelemetry (OTel) supports both Auto Instrumentation and Manual Instrumentation across most popular programming languages. Each approach has clear strengths and limitations, and in practice, organizations often evolve from one to the other as their observability maturity grows.
In the early stage, many organizations choose Auto Instrumentation to accelerate adoption. With minimal or no code changes, teams can onboard applications quickly, significantly reducing development effort and speeding up time‑to‑value.
However, as more and more applications are migrated to OpenTelemetry, strategy often shifts. Organizations gradually move toward Manual Instrumentation—for both existing services and new features—to better control telemetry volume and reduce ongoing costs such as bandwidth usage, APM licensing, and infrastructure overhead.
This shift doesn’t come for free. Manual Instrumentation introduces additional development effort, and logs usually need continuous enhancement because their coverage area is more limited and intentional compared to auto‑generated data.
✅ Auto Instrumentation\
Pros\
· No code changes required\
· Integrates via language‑specific libraries/agents\
· Faster application onboarding\
· Easier initial troubleshooting due to broad, automatic coverage\
Cons\
· Application performance impact is higher\
· Higher cost (bandwidth, compute power, APM license fees)\
· Limited ability to add custom business or domain‑specific context to traces
✅ Manual Instrumentation\
Pros\
· Full control over what gets instrumented\
· Supports adding customized and business‑relevant information to traces\
· Lower long‑term cost (reduced telemetry volume, infrastructure, and license usage)\
· Application performance impact is Lower
Cons\
· Requires code changes\
· Slower onboarding process\
· Additional development effort and ongoing log enhancements
📌 Key takeaway\
There is no single “right” choice.\
· Auto Instrumentation is ideal for fast onboarding and early visibility.\
· Manual Instrumentation becomes essential for cost optimization, precision, and richer business context at scale.
Most mature observability strategies use a hybrid approach—starting with auto instrumentation and progressively refining critical paths with manual instrumentation.
What has your experience been with OpenTelemetry adoption? Auto first, manual later—or a mix from day one? 👇
## 🚀 Let's Connect Beyond GitBook!
If you found this article helpful, you can find more of my technical insights, daily discussions, and deep dives across these platforms:
* **Read more of my work:** Check out my articles on [dev.to](https://dev.to/stephen_tsoi_5b2c4055f3a9) and [Hashnode](https://stephentsoi.hashnode.dev/).
* **Join the daily conversation:** Connect with me directly on [LinkedIn](https://www.linkedin.com/in/stephen-tsoi-16309730/).
***
#### 📬 Stay Ahead of the Curve
Enjoyed this piece? I break down complex technical topics into bite-sized, actionable insights every week.
👉 **Subscribe to my** [**LinkedIn Newsletter**](https://www.linkedin.com/build-relation/newsletter-follow?entityUrn=7487299517642612736) to never miss an update and get the latest articles delivered straight to your feed!
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/opentelemetry/from-missing-events-to-complete-visibility-tracing-enterprise-transactions-with-opentelemetry/day-5-34-auto-instrumentation-vs.-manual-instrumentation-its-all-about-trade-offs.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
