Skip to content
ChannelWatch

Delivery Log

The delivery log helps you distinguish an accepted send, a retry, a failure, and an attempt skipped because a destination keeps failing.

Open and filter the log

Section titled “Open and filter the log”
  1. Open Notification Log from the navigation, or Logs in the mobile bottom bar.
  2. Use the app’s DVR selector to narrow the server scope.
  3. Filter by Channel, Status, or the date range.
  4. Refresh after a new delivery. Results are paged in groups of 50.
ChannelWatch notification delivery log table with sent, retry, channel, event type, payload size, and error columns
Delivery log tableDelivery logs show per-alert status, retry count, payload size, and receiver errors. Captured from ChannelWatch v1.6.0 with safe demo data.View full-size screenshot

The log is most useful when you are answering questions like these:

  • Did this alert send successfully?
  • Did ChannelWatch retry it or fail immediately?
  • Is one provider path currently being skipped because its circuit is open?

What each row shows

Section titled “What each row shows”

The desktop table and mobile cards show:

Column Description
Time When the attempt was recorded
Channel Which delivery path was used, such as an Apprise-backed provider or webhook
Event type Which alert type triggered the send
Status sent, retry, failed, or circuit_open
Retries Retry count for that recorded attempt
Payload Estimated notification payload size in bytes, not the downloaded artwork size
Error The captured error message when one was available

ChannelWatch stores one row per recorded attempt, not one row per alert. A single alert can produce several rows for different destinations or retries. The database also records the DVR, provider type, and destination identity even though these are not all separate table columns.

Retry behavior

Section titled “Retry behavior”

When the retry helper is enabled for a delivery path, ChannelWatch uses these retry delays:

Attempt Delay before retry
1st retry 2 seconds
2nd retry 4 seconds
3rd retry 8 seconds
4th retry 16 seconds
5th retry 32 seconds

That allows up to six attempts for one send, including the initial attempt. An open circuit can stop the sequence earlier.

Live-TV, VOD, and runtime Apprise alerts use a single manager-level attempt. Other eligible Apprise alerts use bounded retries. Native webhooks have their own three-attempt retry loop, so the shared log records the overall webhook result rather than every HTTP request.

Retry and circuit state are tracked by DVR, delivery channel, provider type, and destination ID. For example, a failing Discord destination does not open the Telegram destination’s circuit for that DVR. Native webhook endpoints are currently represented as one webhook group.

Circuit breaker

Section titled “Circuit breaker”

The circuit breaker prevents repeated attempts against a delivery path that is already failing.

Current v1.6.5 behavior in the retry helper is:

  1. After 5 consecutive failures for a destination identity, the circuit opens.
  2. While open, ChannelWatch skips that destination and records circuit_open.
  3. After 5 minutes, the circuit closes automatically and delivery resumes.
  4. A successful send resets that destination’s failure counter.

Rows with status circuit_open mean ChannelWatch skipped the delivery attempt because the circuit was open at that moment.

Retention

Section titled “Retention”

Delivery-log rows are stored in channelwatch.db and pruned by the nightly maintenance job.

The retention window is tied to ChannelWatch’s configured history retention, not a hardcoded 30-day delivery-log limit. In the current source, the default history retention is 90 days unless you change it in settings.

Status reference

Section titled “Status reference”
Status Meaning
sent The provider accepted the send. For native webhooks, at least one enabled endpoint accepted the payload
retry Delivery failed and another retry-enabled attempt is scheduled
failed Delivery failed and no more attempts will be made for that send
circuit_open Delivery was skipped because this destination’s circuit was open

sent is not a read receipt or a guarantee that every device displayed the message. For multiple native webhook endpoints, inspect the receiver and container logs if you need to confirm each endpoint separately.

Troubleshooting

Section titled “Troubleshooting”

Repeated failed rows for one channel

Section titled “Repeated failed rows for one channel”

Check the error column for the specific failure reason. Common causes:

  • Invalid credentials, webhook URL deleted, API token revoked, or bot removed from the channel. Update the provider settings and test again.
  • Network unreachable, the ChannelWatch container cannot reach the destination service. Verify DNS and outbound connectivity from the container.
  • Provider-side rejection, the remote service rejected the request. Check the provider’s own limits and error text.

Circuit breaker keeps reopening

Section titled “Circuit breaker keeps reopening”

If the circuit opens, closes, and opens again repeatedly, the underlying delivery problem still exists. Fix the root cause instead of waiting for the circuit window to cycle.

Log is empty

Section titled “Log is empty”

Check the DVR and date filters first. The log contains delivery attempts, not every detected activity event. An alert disabled by its preset or routing will not create a successful-send row. If needed, use the v1.6.5 test guidance to deliberately send a real message to configured destinations.

Section titled “Related pages”