Pylon SLA Breach Deadline Sentinel

Pylon tracks a resolution SLA deadline on every issue, but nothing in Pylon itself pages anyone the moment that deadline passes while the issue is still open. This blueprint reads that deadline directly, resolution_breach_time, rather than guessing from how old an issue looks, and alerts the moment it has passed on an issue that is not closed.

This blueprint was created by Mohit Jeswani.

How it works

1. list_issues (io.kestra.plugin.pylon.issue.List) fetches every issue updated within lookback_days. Read-only; nothing in Pylon is changed. allowFailure: true covers an API or auth error without failing the flow outright.
2. evaluate (io.kestra.plugin.core.output.OutputValues) filters to issues where state is not closed and resolution_breach_time is on or before today, counting them and collecting their titles with a jq filter.
3. route (io.kestra.plugin.core.flow.If):
   • compliant: logs that nothing has breached.
   • alert: posts the count and titles to Slack.
4. summary logs the count and severity, closing the governance cycle.
5. errors alerts Slack if the flow itself fails, for example an expired API token.

What you get

• A governance check built on Pylon's own SLA deadline field, not an inferred "this looks old" heuristic, so it only ever fires on an actual, declared SLA breach.
• The exact issue titles in the Slack alert, not just a count.
• A read-only check with zero risk of touching a real issue.

Who it's for

• Support and customer success teams running Pylon who want SLA breaches surfaced the moment they happen, not discovered during a weekly review.
• Teams evaluating the Pylon plugin who want a worked example of issue.List used against a real SLA field rather than a generic status filter.

Why orchestrate this with Kestra

Pylon computes and stores the SLA deadline; it does not decide a cadence, compare it to the issue's current state, or notify a specific Slack channel the moment it passes. Kestra keeps lookback_days and max_breached_count as flow inputs, turns the check into a Slack page naming the actual breached issues, and keeps a full execution history of every run.

Prerequisites

• A Pylon account with issues that have SLA policies applied, so resolution_breach_time is actually populated on at least some issues.
• A Pylon API token with read access to issues.
• A Slack incoming webhook URL.

This flow calls the Pylon API directly over HTTPS; there is no official local Pylon emulator, so list_issues cannot be exercised against a local Docker container. Validate against a real account with at least one issue past its SLA deadline.

Secrets

• PYLON_API_TOKEN: the Pylon API token used by list_issues. In Kestra OSS, provide it as the base64-encoded environment variable SECRET_PYLON_API_TOKEN.
• SLACK_WEBHOOK_URL: used by alert and the errors block. In Kestra OSS, provide it as the base64-encoded environment variable SECRET_SLACK_WEBHOOK_URL.

Inputs

Input	Default	Purpose
lookback_days	90	Bounded time range issue.List scans, max 365
max_breached_count	1	Breached-issue count that triggers the Slack alert

Outputs

• {{ outputs.list_issues.rows }}: every issue in the window (title, state, resolution_breach_time, first_response_breach_time, created_at, and more).
• {{ outputs.evaluate.values.breached_count }} / .breached_titles: how many issues have breached and their titles, semicolon-joined.
• {{ outputs.evaluate.values.severity }}: OK, SLA_BREACH, or CRITICAL.

Pitfalls

• lookback_days bounds what issue.List even considers; an issue last updated before that window is invisible to this check even if it is still open and long past its SLA. Pylon caps the range itself at 365 days.
• resolution_breach_time compares by date only (its first 10 characters), not by hour or minute; an issue that breaches later today is not yet flagged until tomorrow's date rolls over in this comparison.
• resolution_breach_time is only populated when an SLA policy actually applies to the issue; issues with no SLA policy are correctly excluded, not false positives, but also never checked.
• first_response_breach_time is a separate SLA deadline this blueprint does not check; a first-response breach on an issue that later meets its resolution SLA will not be flagged.

Quick start

1. Add the PYLON_API_TOKEN and SLACK_WEBHOOK_URL secrets.
2. Run the flow with the defaults against a real account and confirm summary logs a count.
3. If no issue has breached yet, find or create a test issue whose SLA deadline has already passed and confirm alert fires with its title.
4. Enable the hourly trigger once lookback_days and max_breached_count reflect your own support SLA policy.

How to extend

• Add a second evaluate block checking first_response_breach_time the same way, for a complete first-response and resolution SLA gate in one flow.
• Group by team_slas in a downstream task to route each team's breaches to its own Slack channel instead of one shared alert.
• Read business_hours_resolution_seconds to report how far past SLA an issue is, not just that it has breached.

Links

• Pylon plugin: https://kestra.io/plugins/plugin-pylon
• Pylon Issues API reference: https://docs.usepylon.com/pylon-docs/developer/api/api-reference/issues.md
• Slack incoming webhooks: https://api.slack.com/messaging/webhooks