Alerts & Log Streaming

Every detection Kansyn makes — a Domains Incident, a Social Media impersonation hit, an Ads unauthorised advertiser, a Breach Monitor finding — is emitted as one uniform event and handled two ways at once.

Alerts & Incidents (the in-app feed)

Every event lands in the Alerts & Incidents feed automatically, whether or not you've configured anything else. From there you can:

• Filter by severity, product, or read/dismissed state
• Mark items read or dismiss them
• Save a named filter (e.g. "Critical, unread") as a Saved View for quick recall — shared across your whole team, not just you

This feed exists independently of Log Streaming — a brand-new org with zero integrations configured still gets full visibility here.

Log Streaming (external forwarding)

If you want findings in your own tooling as well, configure a destination under Log Streaming. Six types are supported:

| Destination | Typical use | |---|---| | Webhook | Generic HTTPS POST — covers most SOAR tools | | Slack | Formatted alert messages in a channel | | Email | Plain notification email | | Splunk HTTP Event Collector | Enterprise SIEM ingestion | | Syslog (TCP/UDP/TLS, RFC5424 or CEF) | Traditional SIEM ingestion — QRadar, ArcSight, etc. | | S3-compatible bucket | Pull-based ingestion — Datadog, Sumo, your own log lake |

Each destination has its own minimum severity — set it to high and you'll only hear about high/critical events on that channel, while everything still shows up in the in-app feed regardless.

Delivery is best-effort: a failed delivery to one destination is logged and skipped, not retried — the in-app feed is always the reliable fallback.

Testing a destination

After creating a destination, use its Test action to send a synthetic event through it immediately (bypassing the severity gate), so you can confirm it's wired correctly before relying on it.