README

Winter CMS plugin — reports application exceptions to a configurable HTTP webhook endpoint (JSON POST + Bearer token).

Lightweight, no external dependencies: ideal for hooking up a custom worker, n8n, Zapier, or any API that accepts JSON.

Installation

Composer (recommended)

composer require quendistudio/monitoring
php artisan winter:up

Manual

Clone into plugins/quendistudio/monitoring, then:

php artisan winter:up

Backend → Settings → Monitoring (QuendiStudio Plugins category). Full documentation is also available in the Documentation tab of the settings page.

Grant the quendistudio.monitoring.access_settings permission to the relevant administrators.

Configuration

Which exceptions are reported?

Winter’s built-in $dontReport list (in Handler.php) tells the core not to log certain exception types to the application log — it does not mean they are unimportant. This plugin hooks exception.beforeReport, which runs before that filter, so the following are included when they reach the exception handler:

• ApplicationException, ValidationException, AjaxException
• HTTP, authentication, and model-not-found exceptions
• Any other Throwable passed to Handler::report()

Not reported: exceptions caught and handled before report() is called (expected control flow, successful validation redirects, etc.).

Sensitive data in payloads

The JSON payload is designed for automated analysis. It may contain:

• Full exception messages and stack traces
• Request URL including query string (tokens, emails, etc.)
• Tail of storage/logs/system*.log (may include secrets from log context)

Ensure the webhook endpoint and downstream services (agent, email provider) are trusted and secured. Restrict backend access to Monitoring settings.

JSON schema

Each exception triggers a POST to webhook_url with headers:

Content-Type: application/json
Authorization: Bearer {webhook_secret}
User-Agent: Quendistudio.Monitoring/1.0

Root fields

exception object

request object

Example (real exception)

{
  "event": "winter.exception",
  "source": "quendistudio.monitoring",
  "site_id": "mywebsite-www",
  "site_url": "https://www.example.com",
  "platform": "wintercms",
  "occurred_at": "2026-06-15T14:30:00+02:00",
  "exception": {
    "class": "Winter\\Storm\\Exception\\ApplicationException",
    "message": "Something went wrong",
    "file": "/var/www/plugins/vendor/plugin/SomeClass.php",
    "line": 42,
    "code": 0,
    "trace": "#0 /var/www/index.php(42): ..."
  },
  "request": {
    "url": "https://www.example.com/page",
    "method": "GET",
    "ip": "203.0.113.1",
    "user_agent": "Mozilla/5.0 ..."
  },
  "logs_tail": "[2026-06-15 14:29:58] production.ERROR: ..."
}

Example (test payload)

Same as above, plus "test": true and a simulated message.

Adapting your endpoint

The plugin sends a generic JSON format. Your endpoint (or an intermediary) is responsible for:

• validating the Bearer token;
• parsing the exception, request, and logs_tail fields;
• triggering the desired action (email, ticket, centralized logging, etc.).

Integration examples:

• Serverless worker (Cloudflare Workers, AWS Lambda): receive the POST, format an email or alert.
• n8n / Zapier / Make: webhook trigger → map JSON fields to Slack, email, database.
• Internal API: store errors in your own monitoring system.

Extension plugins for native formats (Slack, Discord, Sentry, etc.) may be developed later; this plugin deliberately focuses on the generic webhook.

Tests

# Test JSON payload (without throwing an exception)
php artisan monitoring:testwebhook

Intentional exception route (Development tab):

1. Enable Allow test route
2. Ensure APP_DEBUG=true
3. Open /quendistudio/monitoring/test-exception

Do not enable the test route in production.

Application flow

Winter Handler::report()
  → exception.beforeReport (this plugin)
  → ExceptionPayloadBuilder (JSON)
  → ErrorReporter (deduplication after successful POST, async at end of request)
  → Your webhook

Appendix: Cursor Automation integration

Cursor Automations can act as a webhook receiver with a Webhook trigger:

1. Create an automation with a Webhook trigger.
2. Copy the URL and authentication key into Webhook URL and Webhook secret.
3. Configure the agent prompt to analyze the JSON payload (exception, logs_tail, request).
4. Optional: chain a second webhook (email, Resend, Slack, etc.) from the automation.

The JSON schema documented above can be used directly by the Cursor agent — no transformation on the plugin side is required.

License

MIT — see LICENCE.md.