tech-news · 28 August 2026
ChatGPT Tasks Can Now Wake on Gmail, Slack and GitHub Events
OpenAI has added event triggers for Gmail, Slack and GitHub, moving ChatGPT tasks from clock-driven jobs towards reactive automations with useful limits.
OpenAI changed ChatGPT tasks on 25 August so they can start when something happens in Gmail, Slack or GitHub. Until now, the built-in scheduler was mainly a clock: run this later, every morning, or every Friday. The new event triggers let a task wait for matching activity and then run its saved prompt. OpenAI calls these webhook-triggered tasks , although the user does not have to host a webhook endpoint.
That sounds like a small addition to a scheduler. In practice, it moves ChatGPT closer to the reactive automation tools people already build with webhooks, queues and integration platforms. The trigger decides when work begins; the prompt decides what the task does. ChatGPT supplies the conversational setup and the connection to the supported app.
What changed this week
Gmail triggers can respond to new messages and filter them by sender or subject. Slack triggers watch new messages in selected channels. GitHub triggers concentrate on pull-request activity in an authorised repository. The current task documentation describes filters for pull request, author, title and label, with reviews, comments, commit updates and merges available as trigger conditions.
The integrations have deliberate edges. ChatGPT must be added to every Slack channel a task watches, and the connected GitHub app must have access to the relevant repository. Slack reactions, edits, deletions and direct messages are not supported as triggers. A single task may use several event triggers, but it cannot combine them with a time-based schedule.
OpenAI also warns that matching events arriving close together may be combined into one run. Pending events and completed runs appear in Scheduled, where a task can be reviewed, paused, edited or deleted. Actions that require approval may stop and wait for a person rather than proceeding unattended.
This first release is narrower than the name might suggest. Event-triggered tasks require ChatGPT Work and an eligible Plus, Pro, Business, Enterprise, Edu or Healthcare account. Free and Go users can create ordinary scheduled tasks but not webhook-triggered ones. Managed workspaces may also require an administrator to enable the feature.
Why it matters
Polling is a clumsy answer to an event-shaped problem. A job that checks GitHub every ten minutes spends most of its runs discovering that nothing happened, then introduces up to ten minutes of delay when something does. An event trigger can start closer to the arrival of new work and avoids those empty checks.
Pull-request feedback is an obvious use. A task could wake when a review lands, collect the comments, identify the affected areas and prepare a revision plan. A merge-only trigger could assemble a release-note draft or a deployment checklist. Neither example requires the task to make an irreversible change; it can do the dull first pass and leave judgment with the developer.
Email and Slack offer similar patterns. A narrowly filtered Gmail trigger could summarise messages from a monitoring service and prepare an action list. A Slack task could turn a burst of project-channel feedback into a short brief. Those jobs no longer need a fixed cadence simply because a scheduler was the only available starting mechanism.
The convenience does not remove the usual automation risks. Connected apps expose real work data, and the saved prompt controls what happens after the trigger fires. A read-and-summarise task with a specific sender, channel or repository filter is easier to reason about than a broad task allowed to modify external systems. The safer starting pattern is to inspect, summarise and prepare, with an explicit approval boundary before consequential writes.
Batching needs attention too. If several events can become one run, the prompt should not assume every invocation contains exactly one email, comment or review. It should enumerate the items received, handle duplicates safely and report incomplete inputs. Conversational setup makes an automation easier to create; it does not make idempotency or audit trails optional.
There is another practical boundary between cloud context and local work. The web task can use its connected apps and available tools, but this event-trigger release is not the same as keeping a local checkout, build environment or long-lived worker online. Work that depends on local files, private development tools or persistent state still needs an appropriate execution environment.
What to watch next
OpenAI documents the supported events and access requirements, but the two recorded sources do not provide a detailed delivery contract. They do not state a maximum delivery delay, a retry schedule, or a promise that every matching event will produce a separate run. The explicit batching behaviour is enough reason to test a workflow before relying on it for critical operations.
The useful evidence will be operational rather than theatrical: how consistently filters behave, what failed runs do, whether the triggering event is clear in the run history, and whether administrators can reconstruct what an automation saw and changed. Broader event coverage would help as well. GitHub issues, releases, workflow failures and security alerts are natural candidates; calendars and ticket systems would extend the pattern beyond messages and pull requests.
For now, this is a practical bridge between reminders and a full integration platform. It lowers the effort needed to build a reactive assistant around three widely used services, while leaving enough constraints that narrow permissions, careful prompts and human approval still matter.