How to monitor

This page documents Prisma's observability hooks — the ones present in the prisma/prisma runtime that downstream applications can wire into their monitoring stack.

prisma/prisma itself is a library/CLI repo, not a long-running service, so this page does not describe a SaaS-style monitoring posture. Instead it describes the hooks Prisma Client and Prisma Migrate expose so the user's application can observe them.

Logging

Prisma Client emits typed log events when configured with the log constructor option:

const prisma = new PrismaClient({
  log: ['query', 'info', 'warn', 'error'],
});

prisma.$on('query', (e) => {
  console.log('SQL:', e.query, 'duration:', e.duration);
});

Levels: query, info, warn, error. They can be emitted as events (with $on) or printed to stdout ({ level: 'query', emit: 'stdout' }).

The implementation is in packages/client/src/runtime/getLogLevel.ts and threaded through the runtime in packages/client/src/runtime/getPrismaClient.ts.

Internal debug logging across packages goes through @prisma/debug (a thin wrapper over debug):

DEBUG="prisma:*" prisma generate
DEBUG="prisma:client" node ./app.js

Each subsystem registers under prisma:<area>. Greppable: Debug( calls in source.

Metrics

The Client doesn't ship a built-in metrics emitter. Backends sit downstream and observe through:

• The query log level (per-query timing)
• OpenTelemetry spans (see Tracing below)
• SQL Commenter comments propagated into the database (Postgres pg_stat_statements, MySQL Performance Schema, etc.)

When integrating with a metrics backend:

1. Subscribe to query log events for per-query duration
2. Wrap operations in OTel spans for tracing-derived metrics (latency histograms, error rates)
3. Configure SQL Commenter plugins to attach correlation IDs, then mine them in your database's SQL stats

Tracing

@prisma/instrumentation provides OpenTelemetry auto-instrumentation:

import { registerInstrumentations } from '@opentelemetry/instrumentation';
import { PrismaInstrumentation } from '@prisma/instrumentation';

registerInstrumentations({
  instrumentations: [new PrismaInstrumentation()],
});

Once registered, every PrismaClient operation (findMany, create, $transaction, etc.) emits a span. Span hierarchy mirrors the Query execution flow: a top-level operation span, child spans for individual SQL statements, and (when applicable) a transaction span.

The instrumentation contract between @prisma/client and @prisma/instrumentation lives in @prisma/instrumentation-contract. The decoupling lets the Client emit spans without taking a hard @opentelemetry/api dependency.

For SQL-level distributed tracing, register @prisma/sqlcommenter-trace-context:

new PrismaClient({ comments: [traceContextPlugin()] });

This appends the W3C traceparent header to every outgoing SQL statement, so APM tools (Datadog, Honeycomb, etc.) can correlate the database query to the parent application trace.

See SQL Commenter for the full plugin set.

Alerting

prisma/prisma itself doesn't ship alerts (it's not a service). For applications using Prisma Client, common signals to alert on:

• Spike in error log events
• Spike in OTel span error rate
• Latency regressions in span duration histograms
• Connection pool exhaustion (visible in adapter-side metrics)
• Migration failures (prisma migrate deploy non-zero exits in CI/CD)

For Prisma's own dependents (Accelerate, etc.), the relevant alerts live in those services — out of scope for this wiki.

See also

• Query execution for the data flow
• SQL Commenter for SQL-level correlation
• @prisma/instrumentation
• Debugging for the contributor-side debug logs