Repository navigation
Conversation
Currently a notification (via APPRISE_SIDECAR_URL) is only sent when a service update succeeds or fails. If a service is skipped because no update is available, nothing is sent - so a consumer of the webhook (e.g. a monitoring system) can't distinguish "never checked" from "checked, nothing to do" from "still broken since the last failure". Add an opt-in NOTIFY_LEVEL variable: - UPDATE (default): current behavior, unchanged - ALL: also send a "success" notification when a service is checked but does not need an update Fully backwards compatible - default behavior is identical.
…se-shaped payloads
send_notification() currently always posts an Apprise-shaped payload
({"title", "body", "notify_type"}) to APPRISE_SIDECAR_URL. That's a
good fit for actual notification services, but awkward for anything
that wants to programmatically consume these events (monitoring
systems, custom webhook receivers): the service name and event type
are embedded in free-text title/body strings that have to be parsed
back out.
Add an opt-in NOTIFY_FORMAT variable (paired with NOTIFY_LEVEL - both
prefixed NOTIFY_ since they configure the same notification pipeline):
- DEFAULT (default): current Apprise-shaped behavior, byte-for-byte
identical title/body text to before
- JSON: sends a flat, structured payload instead:
{"service", "event", "status", "hostname", "timestamp", "message"},
where "event" is one of image_missing/update_failed/updated/up_to_date
Refactored send_notification() to take structured arguments (service
name, event, status, detail message) instead of pre-built title/body
strings, and builds either shape from those depending on NOTIFY_FORMAT.
As a side effect this also removes the repeated title/body/$(date)
construction at each call site.
Fully backwards compatible - default behavior and payload shape are
unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What i changed
NOTIFY_LEVELto optionally notify on every check, includingup_to_dateNOTIFY_FORMAT=JSONfor structured webhook payloadssend_notification()to work with structured dataWhy
Currently, notifications are only sent when an update succeeds or fails. This means downstream processes can't distinguish between a service that was never checked and one that was checked and is already up to date.
JSON output also makes it easier for downstream systems like Zabbix to process the events without parsing human-readable text.
Both options are opt-in, so the default behavior stays unchanged.
I tested all four event types (
image_missing,update_failed,updated,up_to_date) in both default and JSON mode.Also verified that the default output remains unchanged and tested the JSON output with a standalone docker swarm and a custom Zabbix receiver acting as an Apprise upstream service.
Cheers