honeybadger-errors

Honeybadger Error Tracking

Standard Pattern

from honeybadger import honeybadger

honeybadger.notify(
    exception,
    error_class="DescriptiveErrorCategory",
    context={
        "operation": "what_was_being_attempted",
        "user_id": user.id,
        "item_id": item.id,
    }
)

Error Classification

Use meaningful error_class values for grouping:

General Categories

• APIError - External API failures
• ValidationError - Input validation failures
• DatabaseError - Database operation failures
• ConfigurationError - Missing or invalid configuration
• AuthenticationError - Auth/permission failures

Specific When Needed

For high-volume errors, use vendor-specific classes:

• StripeAPIError - Stripe API failures
• AWSServiceError - AWS service failures
• RedisConnectionError - Redis connection issues

Context Best Practices

Always Include

context = {
    "operation": "what_was_being_attempted",
    "retry_attempt": 1,
    "user_input": relevant_input_data,
}

Use Human-Friendly Identifiers

We use email addresses and names, not database IDs:

context = {
    "user_email": user.email,
    "order_number": order.number,
}

What to Avoid

We don't use tags (use context instead). We avoid generic error classes (Error, Exception), sensitive data (API keys, passwords), and redundant info.

Implementation Example

try:
    result = external_api.call()
except APIException as e:
    honeybadger.notify(
        e,
        error_class="ExternalAPIError",
        context={
            "api": "stripe",
            "operation": "create_payment",
            "customer_id": customer.id,
            "amount": str(amount),
            "status_code": getattr(e, 'status_code', None),
        }
    )
    raise

Error Class Naming

We use PascalCase ending with Error. We're specific enough to group similar issues, but general enough to avoid too many unique classes. We use the same error class for the same failure type across the codebase, and we check existing error classes before creating new ones.