Skip to content

config doesn't filter Events in Discord messages (ref #175) #416

Closed

Description

@teyhouse

Description:
Configuring reasons to exclude event types doesn't affect Discord's Events section - only determines what kwatch monitors, not what appears in notifications.

Config:

reasons:
- '!Scheduled'
- '!Pulling'
- '!Pulled'
- '!Created'
- '!Started'

Expected: Filtered events excluded from Discord Events field
Actual: All events appear, including filtered ones

This causes Discord 1024 character limit errors (similar to #194) and makes notifications noisy.
Related to #175 (Events and Logs section selector) opened Dec 2022, still unresolved.
Requested fix: Either ignoreEventReasons config or boolean to disable Events section.

Activity

  1. abahmed commented on Mar 29, 2026

    @abahmed
    Owner

    Released on v0.10.5 🎉

  2. abahmed commented on Oct 28, 2026

    @abahmed
    Owner

    Hi @teyhouse, thanks again for the Discord event-filtering report. kwatch v1.0 is out: it groups related alerts into one incident with the likely root cause, so fifty alerts become one message.

    Install or upgrade in one line:

    bash <(curl -fsSL https://kwatch.dev/kwatch.sh)

    Pro is free during early access, from the installer's License / Pro menu. I'd love to hear how it works on your cluster, good or bad.

  3. teyhouse commented on Oct 28, 2026

    @teyhouse
    Author

    Hi @abahmed ,
    seems good so far, here is an example alert:
    https://i.imgur.com/Si9MbbA.png

    I am a bit sad though since the Discord Embed is gone. That always gives those notifications are more clear / nice looking structure.
    Thanks for the update!

  4. abahmed commented on Oct 29, 2026

    @abahmed
    Owner

    Thanks for testing and for the feedback, @teyhouse!

    The Discord embed is back in v1.2.0-rc.2. It now has a status colour bar, the cause as the title, and the details in the embed description. The description holds up to 4096 characters, so the old 1024-character field limit from this issue and #194 no longer applies. Threads (?thread_id=) still work.

    Pro alerts also now include the evidence kwatch gathers itself: pod state, logs, events, usage and related objects. So you get the confirmed cause and the fix without running kubectl describe or logs yourself.

    Would love to hear how it looks on your side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions