Ask Claude to Add Logging and Observability to Your Code Without Changing the Logic

You can't debug what you can't see. Adding logging and observability is important but tedious — you need to know what to log, where to log it, and how to structure it consistently. Claude reads your code and instruments it systematically.

Add structured logging to all service methods in src/services/. 
Log the method name, input parameters (redacting sensitive fields), 
execution duration, and outcome (success/failure). Use our existing 
logger from src/lib/logger.

Claude reads each method, identifies the key events worth logging, and adds instrumentation without changing the business logic:

// Claude adds timing and structured context automatically
async function processOrder(order) {
  const start = performance.now();
  logger.info('processOrder.start', { orderId: order.id, itemCount: order.items.length });
  
  try {
    const result = await executeOrder(order);
    logger.info('processOrder.success', { 
      orderId: order.id, 
      durationMs: performance.now() - start 
    });
    return result;
  } catch (error) {
    logger.error('processOrder.failed', { 
      orderId: order.id, 
      error: error.message, 
      durationMs: performance.now() - start 
    });
    throw error;
  }
}

Target different observability needs:

# Add performance timing
Wrap all database queries in src/repositories/ with timing. 
Log any query that takes longer than 100ms as a warning.

# Add request tracing
Add a request ID to every log line in the API layer. 
Generate the ID in middleware and pass it through the context.

# Add business metric events
Identify the key business events in the checkout flow 
(cart created, payment attempted, order confirmed, etc.) 
and add analytics-friendly log events for each.

# Add health check data
Instrument the external service calls so we can track 
availability and response times for each third-party dependency.

Ask Claude to match your existing logging conventions:

Read how logging is done in UserService — that's the pattern to follow. 
Apply the same structure to OrderService and PaymentService, which 
currently have no logging at all.

Observability is the difference between "it's broken" and "it broke here, at this time, with these inputs" — let Claude add the instrumentation so the next bug is visible from the start.

via Claude Code