ChatGPT Event-Triggered Tasks: Gmail, Slack, GitHub Checklist

Originally published on IndieSeek.

ChatGPT event-triggered scheduled tasks: connect Gmail, Slack, and GitHub without duplicate work

Quick answer

On August 25, 2026, OpenAI added event-triggered Scheduled Tasks for supported Gmail, Slack, and GitHub events. Instead of polling every hour, an eligible ChatGPT task can now start when a matching email arrives, a selected Slack channel receives a message, or pull-request activity occurs. The feature is available on ChatGPT web and mobile for eligible plans; it is not available in the desktop app, Codex CLI, or the IDE extension.

Do not treat this as a generic webhook runner. The trigger decides when a task starts, while the saved prompt decides what it does. Nearby events may be combined into one run, one task cannot mix event triggers with a time schedule, and connected-app access still depends on plan, workspace policy, channel membership, and repository permissions.

Who this is for

This guide is for developers and small teams that want ChatGPT to triage an inbox, summarize selected Slack activity, or react to GitHub pull-request changes without building a separate queue worker first. It is especially useful for review reminders, incident intake, release notes, and change reports where the first safe output is a summary or draft.

If the task will modify a repository, pair this trigger checklist with the untrusted-repository sandbox checklist. If GitHub activity should lead to a code review, use the Codex GitLab review rollout model as a separate identity, diff-coverage, and write-authority gate.

What changed—and what did not

Surface	Confirmed behavior	Boundary
Gmail	New incoming messages can trigger a task, with optional sender or subject filters	The docs do not promise arbitrary Gmail events or a general webhook endpoint
Slack	New messages in selected channels can trigger, optionally filtered by author and thread replies	Reactions, edits, deletes, and direct messages are not supported
GitHub	Pull-request reviews, comments, commit updates, or merges can trigger, with repository and PR filters	The connected GitHub app must already have repository access
Trigger model	One task may use multiple event triggers	It cannot also have a time-based schedule
Delivery	Nearby matching events may be combined into one run	One event does not guarantee one run
Availability	ChatGPT web and mobile on eligible plans and workspaces	Desktop, Codex CLI, and IDE extension do not expose event triggers

OpenAI's older Scheduled Tasks Help Center still contains wording that tasks do not support webhooks. The August 25 changelog and current Learn documentation are newer and explicitly document supported app events. The safe interpretation is narrow: supported product events now exist, but OpenAI has not announced a user-defined webhook API.

Build a trigger contract before creating the task

Write one row for each automation. Do not start with “watch everything.”

Field	Example	Why it matters
Source	GitHub repository owner/repo	Establishes the data boundary
Event	PR review submitted or merge completed	Prevents comments and commits from sharing one vague path
Filter	Label needs-release-note	Reduces irrelevant runs
Read scope	PR title, changed files, review summary	Makes required app access explicit
Output	Draft release-note paragraph	Keeps the first rollout reversible
Forbidden action	No merge, push, send, or external publish	Separates observation from authority
Dedup key	Repository + PR number + head SHA + event class	Survives nearby-event coalescing and retries
Stop condition	No material change since last accepted record	Prevents empty repeated work

For Gmail, use sender plus subject only when both are stable. For Slack, select the smallest channel set and decide whether thread replies matter. For GitHub, prefer a repository, event class, and label filter over a prompt that asks the model to infer which activity is important.

A safe rollout workflow

1. Prove access before automation

Connect and authorize the app interactively. Add @ChatGPT to every Slack channel the task watches, and confirm that the connected GitHub app can access the intended repository. In managed workspaces, verify that an administrator enabled event-triggered Scheduled Tasks. A visible app name is not proof that the task can read the required object or take an action.

2. Test the saved prompt as a normal chat

Use a synthetic email, Slack message, or pull request with no secrets or customer data. Give the prompt the exact input shape you expect and require a structured result:

Goal: summarize one matching GitHub pull-request event.
Allowed inputs: repository, PR number, event class, head SHA, title, diff summary.
Output: material_change, summary, evidence_links, recommended_human_action.
Never: merge, push, comment, send, publish, or change repository settings.
If evidence is missing: return blocked with the missing field.
Dedup key: repository + PR number + head SHA + event class.

Keep the action read-only for the first few runs. A task that drafts a reply is easier to review and reverse than one that sends it.

3. Create one narrow event-triggered task

Choose event triggers, not a time schedule. If you still need a daily digest, make it a separate scheduled task that reads already-recorded results. This separation avoids an ambiguous task that sometimes runs per event and sometimes by clock.

4. Run eight acceptance canaries

Canary	Test	Pass condition
Positive	Send one matching event	One reviewable run appears
Negative filter	Send the wrong sender, label, or channel	No run starts
Unsupported event	Edit/delete/react or send a Slack DM	No false supported-event claim
Coalescing	Send two matching events close together	Both inputs are represented even if one run handles them
Dedup	Replay the same logical event	No duplicate external action or duplicate accepted record
Permission	Remove channel/repository access	Task fails closed and names the missing access
Authority	Prompt an outbound or write action	It remains a draft or asks for human approval
Audit	Inspect Scheduled after completion	Source, event, decision, output, and terminal state are recoverable

Do not count task creation, a pending event, or a generated draft as business completion. Define a terminal outcome such as “review record stored,” “human approved,” or “public URL verified,” depending on the workflow.

5. Promote with a rollback switch

Review the first runs, then widen one dimension at a time: another sender, channel, repository, or event class. Keep a pause owner, a revoke path for each app, and a last-known-good prompt. If coalescing loses evidence or the task repeats side effects, pause it before changing filters.

Decision tree

Is the source Gmail, Slack, or GitHub with a documented event?
  no -> use a separate scheduled check or an external event system
  yes -> is event-trigger access enabled for the plan and workspace?
           no -> stop; do not emulate availability claims
           yes -> can the first output be read-only or a draft?
                    no -> add a human approval boundary first
                    yes -> define filter + dedup key + terminal outcome
                           -> run positive, negative, coalescing, and permission canaries
                           -> promote one source or event class at a time

Common mistakes

• Calling the feature “webhooks” and assuming arbitrary payloads or endpoints are supported.
• Expecting one run per event even though nearby events may be combined.
• Mixing a time schedule and event triggers in the same task.
• Watching a broad Slack workspace or Gmail inbox when a channel, sender, or subject filter is available.
• Treating app connection as proof of channel or repository access.
• Letting a first-run automation send, merge, publish, or modify files.
• Omitting a dedup key and terminal outcome, then counting repeated drafts as completed work.

Copyable rollout record

date / owner / workspace / plan:
task_id / task_title / enabled_state:
source_app / source_scope / event_class / filters:
read_permissions / action_permissions / admin_policy:
saved_prompt_version / dedup_key / stop_condition:
positive / negative / unsupported / coalescing:
dedup / permission / authority / audit:
last_terminal_run / evidence_path:
rollback_owner / revoke_path:
decision: blocked | draft-only | canary | limited-rollout | promote | pause

FAQ

Can an event-triggered task also run every morning?

Not in the same task. OpenAI says a task may use multiple event triggers, but it cannot combine them with a time-based schedule. Use a second task for a daily digest.

Does every Slack message type work?

No. The documented trigger is a new message in a selected channel, with optional author and thread-reply filtering. Reactions, edits, deletes, and direct messages are not supported.

Does one matching event always produce one run?

No. ChatGPT may combine nearby matching events into one run. Design the output and dedup record around a set of source events rather than assuming a one-to-one queue.

Sources

• OpenAI: August 25 ChatGPT and Codex changelog
• OpenAI: Scheduled Tasks and supported app events
• OpenAI Help Center: Scheduled Tasks — older boundary wording checked separately
• OpenAI: sandboxing and unattended task security