Otto

GitHub Issue Reminders: Actions Flag Due Dates, Otto Chases Promises

GitHub Issue Reminders: Actions Flag Due Dates, Otto Chases Promises

Developer configuring an issue reminder

GitHub does not send due-date reminders for issues, so you need to build that layer yourself. Marketplace Actions, milestone and project date fields, scheduled scripts that post to email or Slack, and notification filters for manual triage all work. For follow-ups that span email, meetings, and GitHub together, an integrated assistant like Otto can chase the promise until it closes.

TL;DR:

  • A Marketplace Action is quickest to deploy, while a custom workflow offers routing control but requires maintenance; manual filters suit low volume only.
  • A daily scheduled workflow can comment or email assignees, but email needs stored credentials and project field access requires read permission.
  • Check that cron timing uses UTC, the project number matches exactly, and large synchronized scans do not hit GitHub API rate limits.
  • Issue forms, consistent labels, one due date field, and a named assignee give automation reliable data and direct reminders to an owner.
  • GitHub only automation misses promises made in meetings or email unless someone creates an issue; cross tool tracking can capture commitments before ticket creation.
Otto
Keep follow-ups connected
Otto brings email, calendar, meetings, and commitments into one shared memory, then chases promises until they are closed.

Table of Contents

What GitHub tracks natively and where it falls short

GitHub gives you a notifications inbox with watch settings, custom repository subscriptions, and saved queries like is:saved and is:done that help you triage what matters. You can configure how loudly a repository notifies you and build saved views around labels, mentions, or review requests, all explained in GitHub’s notification settings.

What it does not do is send you a message before an issue’s due date arrives. The scheduled reminder feature GitHub shipped recently is built for pull request reviews, not issues: it nudges reviewers through Slack or Teams integrations when a PR is waiting on them, according to the GitHub changelog on scheduled reminders. Issue follow-ups need their own tooling.

Milestones and project fields fill part of the gap. A milestone carries a due date and tracks progress toward it, and project boards can hold custom date fields, as described in GitHub’s milestone documentation. Neither one pings you before the date hits.

  • Notifications inbox: good for triage, not proactive reminders.
  • Milestones and project date fields: store the date, don’t alert on it.
  • Scheduled PR reminders: built for review requests, not issue follow-ups.

Practical ways to get reminded about open issues

You have five realistic paths, and most teams end up combining two of them.

  • Marketplace Action for due dates: a workflow like Issue DueDate Reminder scans a project’s due-date field on a schedule and notifies the relevant people as the date approaches.
  • Custom scheduled Actions: a workflow that queries project fields or milestones directly and notifies the assignee through a comment, an email step, or a webhook you control.
  • Notification filters for manual triage: saved views and is:done queries work fine when volume is low and someone checks daily rather than relying on a push alert.
  • Chat integration via Actions: a scheduled job that posts a daily or weekly summary of upcoming and overdue issues to Slack or Teams, separate from GitHub’s built-in PR reminders.
  • A lightweight serverless function: a small job on a timer that queries the Issues API, compares dates, and fires a notification through whatever channel your team already watches.

The right pick depends on your repository’s permissions and how much maintenance you’re willing to own. A Marketplace Action is the fastest to adopt because someone else wrote and tested it. A custom script gives you more control over message format and routing but means you maintain the code. Manual triage through filters costs nothing to set up but depends entirely on someone remembering to check, which is the exact problem reminders exist to solve.

Teams managing accountability across more than just code often look at broader workflow tools alongside these options. A shared-inbox and assignment platform built for support-style triage can complement repo-level automation when issue follow-ups overlap with customer-facing work.

Build an Actions-based due-date reminder workflow

Setting up a scheduled reminder takes about twenty minutes once you know the pieces. Here’s a workflow you can adapt directly.

  1. Grant permissions: your workflow needs issues: write and, if you’re reading project fields, repository-projects: read. The default GITHUB_TOKEN covers most of this.
  2. Add secrets if you’re emailing: store SMTP credentials or an email API key as repository secrets rather than hardcoding them.
  3. Reference your due-date field: point the Action at the milestone due date or at a custom project field, using the appropriate inputs like the project identifier and field name, per the Marketplace Action’s documented parameters.
  4. Set the schedule trigger: a cron entry in your workflow YAML, typically running once daily.
  5. Check due dates against today: the Action compares the field value to the current date and flags anything within your warning window.
  6. Post the reminder: a comment on the issue, an email to the assignee, or both, depending on the notification_type input.
  7. Log the run: write a short summary to the workflow output so you can confirm it ran and see what it flagged.
  8. Test with a near-term due date: set a date a day out, run the workflow manually, and confirm the comment or email arrives before relying on the schedule.

Watch for three common issues: cron schedules run in UTC, so a reminder meant for 9 AM local time needs the offset calculated; project_number has to match exactly or the Action silently finds nothing; and the GitHub API rate limit can throttle a workflow that checks too many repositories on the same schedule.

Pro Tip: Run your reminder workflow a few hours before your team’s actual start of day, so overdue flags show up in the morning triage instead of overnight.

Make your issues reminder-ready with templates and labels

Automation only works if the data it reads is consistent, and that starts before the reminder script ever runs.

  • Use issue forms to capture due date, owner, and priority as structured fields instead of free text buried in a description.
  • Standardize a small set of labels, like needs-follow-up or blocked, so a script can filter on them reliably.
  • Assign a specific person or team rather than leaving ownership implicit; a reminder sent to nobody in particular gets ignored. GitHub’s own issues documentation recommends assignees and labels for exactly this reason.
  • Keep a single “next action” field and a single date field. Two issues with the same deadline stored in different places will eventually drift out of sync with each other.

Pro Tip: Audit your open issues once a quarter for ones missing a due date or assignee. Those are the ones your reminder automation will never catch.

Why cross-tool coordination keeps breaking down

Why cross-tool coordination keeps breaking down — overview diagram

Most issue follow-ups don’t die inside GitHub. They die in the gap between a standup where someone verbally agrees to fix something, an email where a client flags a bug, and the actual GitHub issue that may or may not get opened afterward. A comment-based reminder only works if the commitment made it into GitHub in the first place.

The teams I’ve watched handle this best treat the repository as one of several places a promise can live, not the only one. A reminder system that only watches issues misses everything agreed to on a call or buried in a thread. A shared ledger that can see meetings, email, and the repo at once closes that gap, because it catches the promise at the moment it’s made rather than waiting for someone to translate it into a ticket.

— Eddie

Where Otto fits alongside your GitHub reminders

Repository automation handles what happens inside GitHub well. The harder problem is everything that happens around it: the promise made on a call that never became an issue, or the issue that got a reminder comment nobody read because the real conversation moved to email.

Otto

We built Otto to sit across that gap. Otto connects to GitHub alongside email, calendar, and meetings, so a commitment made out loud gets logged next to the issue it relates to in one shared memory, and Otto keeps chasing it until it’s actually closed, not just flagged. Nothing goes out without your approval first. Our Free plan starts the same way: connect your tools, and Otto starts building the ledger. If you want to see how we handle follow-ups in other channels first, our post on stopping missed follow-ups walks through the same pattern applied to email and meetings.

FAQ

Does GitHub have a built-in reminder for issue due dates?

No. GitHub’s scheduled reminders apply to pull request reviews, not issues, and milestones or project date fields store a due date without alerting anyone before it arrives, according to GitHub’s changelog. You need a Marketplace Action, a custom script, or an outside tool to get a proactive alert.

What’s the fastest way to add due-date reminders to GitHub issues?

Install a Marketplace Action such as Issue DueDate Reminder, point it at your milestone or project due-date field, and set a daily schedule trigger. It posts a comment or sends an email automatically once a date falls within your warning window.

How do I prioritize which issues deserve a reminder?

Start with issues that block other work, carry a client-facing deadline, or have slipped past their original date once already. Using consistent labels like blocked or needs-follow-up, as recommended in GitHub’s issues documentation, makes it easy to filter for these automatically rather than reviewing every open issue manually.

How do I handle recurring or overdue reminders without noise fatigue?

Separate your reminder cadence from your escalation cadence: a gentle comment at the due date, then a stronger notification (email or a Slack post) if it’s still open a few days later. Tools built for intelligent notification filtering describe similar tiering strategies for routing only the alerts that need immediate attention.

Why might an automated reminder not reach the right person?

The most common causes are a missing or incorrect assignee, a project_number that doesn’t match the workflow’s input, or a cron schedule running in UTC when the team expected local time. Checking the Notifications REST API’s reason field, documented in GitHub’s API reference, can help confirm whether the notification fired at all.

Sources