Skip to content

Troubleshooting

The 80/20 of "why isn't my digest going out?". Sorted roughly by frequency.

The digest didn't arrive at all

In order of likelihood:

  1. Rule was dropped at parse time. Check the log for "rule must …" or "rule conversion failed". Common causes:
  2. GitLab rule with no filter chips
  3. Linear rule with 0 or 2+ of filter / filterRaw / viewId
  4. GitHub or Shortcut rule with empty filter:
  5. No matches. Preesta sends nothing for empty result sets — by design. The log shows how many rules ran and how many issues each rule matched. Run the same filter directly in the tracker's web UI to confirm.
  6. Recipient resolution skipped everything. mailTo: assignee with a tracker that returned no email for every assignee (GitHub hidden email, GitLab profile without a public email) produces a package with an empty recipient list and the channels silently skip it. Add a Reporter column to the digest temporarily — if the issues render but no email goes out, that's the symptom.
  7. SMTP authentication failed. Look for an "authentication" line in the log. Gmail's "wrong password" usually means you used the account password where an app password is required.
  8. SMTP send queued but blocked. Some providers (notably Gmail) silently drop messages that look spammy when From: is a domain you don't control. Check the SMTP provider's outbound dashboard.
  • "Open in →" lands on an unauthorized page — usually a session issue in the browser (you're logged into account A, link is for workspace B). Re-test in an incognito window.
  • Per-issue link 404s — the underlying issue was deleted between fetch and digest send. Rare; not actionable.
  • GitLab dashboard link is empty — the dashboard filters by the viewing user, not by the token owner. If you click as someone who has no issues matching the chips, you see "no work items". Try in your tracker UI with the same chips manually.

Mutations didn't run

  • Permission error. GitHub: missing repo scope. Linear: API key was created in a workspace where the user doesn't have write. GitLab: token has read_api but not api. Shortcut: token was created with Read-only checked (sct_ro_* prefix instead of sct_rw_*).
  • Mutation body has a missing marker. {{@issueId}} resolved to an empty string because the marker doesn't apply to this tracker — check the rendered body in the log.
  • GraphQL errors envelope. Even with a 200 response, GraphQL APIs can return errors for partial failures. They're logged and the run continues.

The digest is duplicated

  • Two cron invocations of the same tag ran concurrently. Add flock to the cron command, or set concurrencyPolicy: Forbid on the Kubernetes CronJob.
  • Two cron entries fire the same tag. Check the cron tab.
  • Both mailTo: and cc: list the same email — Preesta dedupes within a single package, but if two rules sharing a tag target the same person with different subjects, they'll get two emails. That's by design — one rule, one digest, one email.

Logs are noisy

The default Logger level is Verbose. Production should usually run at Information:

Logger:
  Serilog:
    MinimumLevel: Information

Verbose is only useful when debugging rule conversion or recipient resolution.

Still stuck

  • Re-run at Verbose and search the log for error and warning lines.
  • Run the same filter directly in the tracker's web UI — if no matches there either, the rule is doing the right thing (just nothing to send).
  • Open an issue with the rule (redacted) and the relevant log section.