✅ Summary of What You're Doing

You're currently:

• Logging all errors (both user-induced and system failures) at the ERROR level.
• Differentiating them using a context field like "is_system_error": true/false.

This works, but becomes a pain when filtering large logs.

📘 Community Best Practices & Logging Standards

The PSR-3 logging standard (widely followed in the PHP and Laravel world) defines log levels and intended usage, but it does not dictate exactly what to log at which level in terms of domain logic. However, it does provide strong guidelines:

PSR-3 Log Levels

🧠 How Teams Usually Handle This

🔹 Option 1: Split by Log Level

• System Errors: Use error and above (critical, alert) for things like DB failure, exceptions, service unavailability.
• User Errors: Use warning or notice for invalid input, failed validations, wrong OTP, etc.

✅ Pros:

• Standardized and easy to filter by log level.
• Compatible with most log aggregation tools (e.g., ELK, Sentry, Datadog).

⚠️ Cons:

• May need to update a lot of existing code.
• Slightly subjective—what counts as warning vs error.

Example:

// User enters wrong OTP
Log::warning('OTP verification failed', ['user_id' => 123]);

// DB connection failed
Log::error('Database connection error', ['exception' => $e]);

🔹 Option 2: Keep Using error, Add Context (is_system_error)

What you're doing now is also totally valid — especially if you have centralized log processing (e.g., ELK/Logstash or Loki with Grafana), where you can filter by structured fields.

✅ Pros:

• Maintains a single severity level, useful if your alerting system is only hooked to error logs.
• Minimal code changes required.

⚠️ Cons:

• Relies on structured logs and the ability to filter by context (some tools make this harder than others).

✅ Recommended Practice

You can combine both approaches for maximum clarity and compatibility with community norms:

✔ Final Recommendation:

• Use error and above for system-related failures (crashes, exceptions, DB issues).
• Use warning for user-triggered issues (invalid OTP, validation fails, payment declined).
• Add context fields like error_type: "user" or is_system_error: true for extra filtering power.

This hybrid gives you:

• A consistent log level structure across all tools.
• The ability to create alerts only for actual system problems.
• Cleaner, faster log analysis during incident response.

✨ Bonus Tip

If you're using Laravel with Monolog under the hood, consider using custom channels or processors to enrich logs further or even split logs by type (user.log, system.log, etc.).