Find Missing Application Instrumentation with AI

Updated 6 November 2026 · Standard formula, shown below

AI-assisted instrumentation reviews help you spot important events, properties, logs, traces, or metrics that an application does not capture—or captures inconsistently. You compare what the product should let people measure with what the code actually sends, then verify suggested gaps before changing the application. You will need access to the relevant code and product requirements, plus an AI tool approved for your organization’s data.

What You’ll Need

Application source code: Include the services, client apps, and shared libraries in scope. A repository search or static-analysis tool can help inventory telemetry calls.
A reference for intended behavior: User stories, workflows, API specifications, analytics plans, support cases, or a list of critical business operations.
Existing instrumentation guidance: Event names, required properties, logging conventions, tracing standards, and rules for sensitive data.
An approved AI assistant: Prefer a tool permitted to process your code and requirements. Check its data-handling terms and organizational policy first.
A way to verify findings: Tests, a local or staging environment, telemetry dashboards, and access to the relevant event or trace definitions.

Step-by-Step

Set a specific scope. Choose an application, service, or workflow rather than asking an AI tool to review an entire organization at once. Write down the start and end points—for example, account creation from form submission through successful persistence. Include the code paths and repositories involved.
Define what “missing” means. Decide whether you are looking for absent user-facing events, missing trace spans, unhelpful logs, absent operational metrics, or incomplete event properties. These are different forms of instrumentation. Specify which actions and outcomes need to be observable, such as success, validation failure, timeout, retry, and cancellation.
Build a concise expected-coverage list. Turn requirements into a table with the workflow step, expected event or signal, important properties, and expected outcome. Use existing naming conventions where possible. For example, a payment workflow might require an attempt event, a result, and a failure reason that excludes sensitive payment details. Treat the table as a review checklist, not as proof that every possible event is required.
Inventory what the code already records. Search for instrumentation APIs and shared wrappers, and inspect configuration that may enable or disable telemetry. Look at representative call sites and tests. Include relevant server-side and client-side paths; an event may be emitted in one layer but absent in another. Record the event name, location, properties, and conditions that trigger it.
Give the AI only the context it needs. Provide the expected-coverage list, relevant code excerpts or files, and the instrumentation conventions. Ask it to compare expected signals with actual call sites and return a table containing the workflow step, evidence in code, possible gap, confidence, and verification question. Tell it not to invent API names or assume that an unsearched file has no instrumentation.
Ask for evidence, not just recommendations. Require a file path, function, or code excerpt for every claimed existing signal. For each possible gap, ask which expected behavior is uncovered and what code path might explain the absence. A useful prompt is: “Identify likely instrumentation gaps in these files against this checklist. Separate confirmed evidence from hypotheses, cite locations, and flag uncertainty.”
Check coverage across outcomes and boundaries. Review whether signals cover both successful and failed outcomes, important branches, retries, asynchronous work, and service boundaries. Check that events are emitted once at the intended point and that a trace is propagated where the architecture expects it. Avoid treating every function call as a requirement for a separate event.
Validate each candidate gap yourself. Follow the relevant workflow through the code, including shared helpers and framework middleware. Search for aliases, wrappers, generated instrumentation, configuration, and tests the AI may not have seen. Check whether an event is intentionally omitted, duplicated elsewhere, sampled, or disabled in the environment being reviewed.
Assess usefulness and privacy. Confirm that proposed properties answer a defined debugging or product question and use stable, documented names and types. Exclude credentials, tokens, message contents, payment details, and other sensitive data unless an approved policy explicitly permits a narrowly defined treatment. Prefer a non-sensitive category or outcome over raw user input.
Implement small, reviewable changes. Add only verified signals, following the project’s established telemetry wrapper and conventions. Include tests where practical for required event names, properties, and outcome branches. Do not paste an AI-generated patch directly into production; inspect it like any other code change.
Verify in a safe environment. Run relevant tests and exercise the workflow in local or staging conditions. Confirm that the expected signal appears, has correct property values, is not emitted more than intended, and contains no prohibited data. Check that downstream dashboards or queries can interpret it. Document confirmed gaps, accepted omissions, and follow-up work.

Common Mistakes

Asking a vague question: “Find missing telemetry” gives the assistant no definition of expected coverage. Provide workflows and requirements.
Trusting absence in a code excerpt: Instrumentation may live in middleware, a shared helper, generated code, or another repository. Search before calling it missing.
Confusing more data with better observability: Excessive events create noise and can increase data exposure. Instrument decisions and outcomes that support a clear use case.
Accepting invented details: AI may misread a wrapper or suggest an API that does not exist. Verify every suggested name and code location.
Ignoring failures and privacy: Success-only coverage can hide the most useful evidence, while careless properties can expose sensitive information. Review both explicitly.
Skipping runtime checks: A call in source code does not prove the signal is emitted, correctly configured, or visible downstream.

Tips

Review one workflow at a time and keep a record of files and repositories included in the scan.
Ask the assistant to label findings as confirmed, likely, or uncertain, and to explain what evidence would resolve uncertainty.
Use tests and an instrumentation catalog as stronger references than names inferred from code alone.
Keep prompts and output free of production secrets and unnecessary customer data. Follow your organization’s AI and data-retention policies.
Track accepted gaps and intentional omissions. A documented decision is easier to maintain than an unexplained absence.

Troubleshooting

The AI reports gaps that are already covered: Search for wrappers, middleware, shared libraries, and equivalent signals under alternate names. Add those locations to the context and ask the assistant to revise its comparison, while preserving the evidence for each conclusion.

The results are too broad or repetitive: Narrow the scope to one workflow and specify the signal type and expected outcomes. Ask for unique findings grouped by workflow step, with duplicate recommendations merged.

The assistant cannot read the repository: Use an approved integration if available, or provide a small, relevant set of files and the checklist manually. Do not work around access controls or upload material the tool is not approved to receive.

A suggested event never appears in staging: Check whether the code path ran, the correct environment configuration is active, the event is sampled or filtered, and the telemetry transport is healthy. Inspect application logs and tests, and distinguish an instrumentation defect from a downstream ingestion delay.

A change creates duplicates or noisy dashboards: Identify whether both a caller and shared layer emit the same signal. Choose one appropriate emission point, keep event meaning consistent, and remove or revise the duplicate through normal review.

Frequently Asked Questions

Can AI find every missing instrumentation point automatically?
No. It can compare supplied evidence and identify likely gaps, but it may miss runtime behavior, configuration, or code outside its context. Human validation is essential.

What should I give an AI assistant?
Provide a scoped workflow, expected signals, conventions, and relevant code. Share only information permitted by your organization’s data and tool policies.

Should I instrument every function?
No. Add signals where they answer a defined question, such as whether a critical operation succeeded or why it failed. Excess instrumentation can add noise and data exposure.

How do I distinguish a missing event from an intentionally omitted one?
Check the instrumentation plan, code comments, configuration, privacy rules, and owning team’s decision. Record intentional omissions and their rationale.

Can I use AI-generated code without testing it?
No. Review the change, follow local conventions, run relevant tests, and verify emitted data in a safe environment before release.

How often should I repeat the review?
Repeat it when critical workflows change, new services or clients are added, telemetry conventions are updated, or monitoring reveals an observability gap.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.