Workflow: use Zapier to automate GitHub issue triage

Recommendation
Use GitHub webhooks into a Zapier “Webhook” trigger (push, near real‑time) + Zapier filters/paths for light rule-based triage. Reserve API calls (label, assign) only after classification and filtering. If you need natural language prioritization, call an LLM step (e.g., ChatGPT) but keep it optional and rate‑limited.

Why this works
- Webhooks avoid polling latency and reduce API usage.
- Filtering early in the Zap keeps task consumption low (Zapier charges per task).
- A lightweight “processing” label + idempotency checks prevents double work when retries happen.

Decision criteria (pick approach based on these)
- Repo volume: use webhooks for >1 issue/10 minutes; polling only if you can’t use webhooks.
- Budget & plan: Zapier task costs and rate‑limits matter—if you’re high volume (hundreds/day), consider serverless queue (AWS Lambda/SQS) or GitHub Actions instead.
- Skill level: Zapier webhooks + filters is low code. If you need complex state or long retries, use a serverless approach.
- Team size / SLA: for small teams, Zapier + Slack alerts suffice. For enterprise SLAs, prefer a queue-based architecture.

Recommended triggers & Zap layout
1) Trigger: Zapier Webhooks “Catch Hook” (configure GitHub Issue webhook for issues: opened/edited/reopened). If webhooks are impossible, use Zapier’s GitHub “New Issue”/“Updated Issue” trigger (note: may poll).
2) Step: Zapier Filter — drop low‑priority or bot issues (author is a bot, labels excluded).
3) Step: Classification — rule-based keyword rules first (bug, security, urgent), then optional ML step (ChatGPT) for fuzzy priority detection. Keep ML only for edge cases to save tokens.
4) Step: Paths or Formatter — map classification to label set + assignee/team routing.
5) Action: Add Labels / Add Assignees / Post Comment. Use a guard: check existing labels before adding.
6) Step: Notify Slack/email for high priority.

Rate limits & cost patterns to watch
- GitHub REST API: authenticated requests are typically 5,000/hour per user token (check your token type — GitHub Apps and rate buckets differ). Respect 429 responses.
- Zapier: each action counts as a task — filter early to reduce consumption. Polling triggers cost more tasks; webhooks are cheaper for high throughput.
- LLM step: cost per call (tokens); batch or only call when rules are ambiguous.

Failure handling patterns (practical)
- Idempotency: first check if target label exists; skip if present.
- “Processing” label: add then replace with final label to indicate in‑flight; remove on success.
- Retries/backoff: when you receive a 429 or API error, Delay then retry (exponential backoff: 1m, 5m, 15m). Zapier has limited built‑in retries—persist failed payloads (DLQ) to Google Sheets/Airtable/S3 for manual replay.
- Alerts & DLQ: on permanent failure, tag issue triage:error, post details to a Slack channel and append payload to a Google Sheet for reprocessing.
- Logging: write a compact audit row per issue (timestamp, issue_id, labels_applied, status) to a spreadsheet or Airtable for traceability.

Practical checklist (deploy)
- [ ] Create GitHub webhook for issues -> Zapier webhook URL.
- [ ] Build Zap: Filter early -> Classification -> guard (check existing labels) -> Label/Assign -> Notify.
- [ ] Implement idempotency and “processing” label logic.
- [ ] Add Delay/retry logic and DLQ (Google Sheet/Airtable/S3).
- [ ] Set alerts for repeated failures (Slack/email).
- [ ] Monitor Zapier task usage & GitHub rate headers; tune filters.

Best-for / Avoid-if
- Best for: small-to-medium repos, teams wanting low-code, near real‑time triage, and rule+ML hybrid classification.
- Avoid if: extremely high volume or you need durable, complex stateful workflows—use serverless queues or GitHub Actions.

If you want, I can draft a starter Zap flow (webhook payload parsing, filter rules, and example label mapping) or outline minimal GitHub webhook settings. CTA: use Zapier to implement the webhook trigger and action steps.

Compare Zapier and Make