# imqueueInstrumentation() function · @imqueue/opentelemetry

Source: https://imqueue.org/api/opentelemetry/latest/opentelemetry.imqueueinstrumentation_1/
Published: 2026-08-30
Author: @imqueue maintainers (https://github.com/imqueue)
Package: @imqueue/opentelemetry 4.1.2 — generated reference, not hand-written

Build an [ImqueueInstrumentation](https://imqueue.org/api/opentelemetry/latest/opentelemetry.imqueueinstrumentation/) already bound to the application's own `@imqueue/rpc`, ready to drop into an `instrumentations` array beside any other instrumentation:

```typescript
const sdk = new NodeSDK({
    instrumentations: [
        new PgInstrumentation(),
        await imqueueInstrumentation(),
    ],
});
```

**Signature:**

```typescript
export declare function imqueueInstrumentation(config?: InstrumentationConfig): Promise<ImqueueInstrumentation>;
```

## Parameters


| Parameter | Type | Description |
| --- | --- | --- |
| config | InstrumentationConfig | _(Optional)_ standard OpenTelemetry instrumentation config |


**Returns:**

Promise<[ImqueueInstrumentation](https://imqueue.org/api/opentelemetry/latest/opentelemetry.imqueueinstrumentation/)>

an instrumentation hooked to the caller's `@imqueue/rpc`

## Remarks

Prefer this over `new ImqueueInstrumentation()` in an ESM application.

This instrumentation works by patching `@imqueue/rpc`'s mutable default option singletons, so it has to hold \*the same module object the application holds\*. `enable()` can only reach for that synchronously, with `require`, and that is not always the same instance: under a loader which evaluates ESM and CJS separately — `tsx`, for one — `require` yields a second copy of the module, the hooks are attached to singletons nobody calls, and the result is silence rather than an error. Resolving through `import()` here asks the loader the application itself used, so the instance always matches.

The returned instrumentation is already patched, and `enable()` will not patch it again, so registering it costs nothing extra.