- How do I install dyanakiev/laravel-logger-discord-channel in a Laravel app?
- Install it with Composer, then add a Discord channel entry to config/logging.php and point it at your webhook URL stored in an environment variable or secret store. There are no migrations, schema changes, or runtime services to provision. A single engineer can validate it end to end in under a day, including a test webhook in staging.
- How do I configure the Discord log channel in config/logging.php?
- Add a new channel array to the channels key in config/logging.php using the driver registered by the package, with your webhook URL read from env and an explicit level such as error or above. Keep the webhook URL out of version control because it acts as a bearer credential. Then reference the channel from your default stack or a dedicated stack used by the services that should alert.
- Which Laravel and PHP versions does this package support?
- Version 6.1.4 is a compatibility bump that widens constraints to include Laravel 13.x, and it depends on illuminate/support and Monolog 3.x. If your applications run Laravel 10, 11, or 12, that release is effectively a no-op for you. Check the PHP version floor and run composer why-not against your lockfile before merging to confirm all three constraints resolve cleanly.
- How do I send only errors and critical logs to Discord?
- Set the channel level to error or higher so that debug, info, and notice records stay in your file or centralized log channels. Then append discord to the stack for the environments where alerting is wanted, rather than replacing your existing channels. This keeps Discord as a notification tier layered on top of your normal logging, not a substitute for durable log storage.
- Does it work with Laravel's stack channel and LOG_STACK?
- Yes. The package registers a Monolog handler, so it composes with the standard stack, single, and daily channel model and can be appended to whatever LOG_STACK resolves to. Add it only for the target environment so that local and CI runs do not post to Discord. Because it is additive, rollback is just deleting the channel entry from config/logging.php.
- What happens when Discord rate limits the webhook and returns 429?
- Delivery is fire-and-forget, so when Discord rate-limits a webhook the affected messages are dropped rather than retried with backoff. Logging traffic is bursty, which means alerts are most likely to be lost exactly when incident volume spikes. Test this in staging by deliberately emitting a high volume of errors and observing the 429 behavior before relying on it in production.
- Are long messages or stack traces truncated by Discord's limits?
- Discord caps message bodies at roughly 2000 characters and limits embed counts, so large exception traces can fail or arrive mangled unless they are truncated. If you need the full trace, keep your file or centralized log channel as the source of truth and treat the Discord message as a pointer. Review how your formatter handles multi-line traces before enabling the channel for critical alerts.
- Is it safe to send exception traces containing PII to Discord?
- Exception traces routinely include connection strings, tokens, and end-user data, and this package routes them to a third-party SaaS outside your network boundary. Confirm your security policy permits application error content to leave the perimeter and check outbound HTTPS allowlists and proxy settings for discord.com. Also treat the webhook URL as a secret, since leakage allows channel spam and potential information disclosure if the channel is shared.
- Can I queue or buffer Discord log messages for reliable delivery?
- The package is a thin Monolog handler, so treat it as best-effort alerting rather than a guaranteed delivery path. If you need buffering, deduplication, or rate-limit backoff, verify whether the current release offers it and consider wrapping or queuing the handler yourself. Many teams accept best-effort delivery because file, stderr, and centralized shipping remain the durable record.
- Is the package actively maintained and what are the alternatives?
- It is a single-maintainer package, and the 6.1.4 release is a one-line compatibility bump, which suggests reactive rather than continuous maintenance. Diff 6.1.3 to 6.1.4 on a throwaway branch, pin the version, and review the license and issue-response history over the last 6 to 12 months. If upstream stalls, the code is small enough to fork, and the main alternative it replaces is ad-hoc curl-on-exception code or a Slack-style webhook notifier.