Can ChatGPT Tasks Trigger From Gmail, Slack, and GitHub Now? Webhook Automation Explained

ChatGPT scheduled tasks no longer have to wait for a clock or repeatedly check whether something changed.

As of August 25, 2026, eligible ChatGPT users can create event-triggered tasks in ChatGPT Work that respond to supported events from Gmail, Slack, and GitHub. OpenAI describes these as webhook-based tasks: a supported app event can trigger the task when it happens, rather than relying on a fixed hourly or daily polling schedule.

The important limitation is that this is not a general webhook builder for any website or API. The current documented trigger set is narrow, access depends on the plan and workspace, and any external action can still stop for approval.

Feature check — August 27, 2026: OpenAI’s current Scheduled Tasks documentation lists event-triggered tasks for eligible Plus, Pro, Business, Enterprise, and Edu accounts, plus eligible ChatGPT for Healthcare workspaces. Free and Go accounts cannot create event-triggered tasks. Work and the required connected app must be available for the account or workspace.

The quick answer

The simplest mental model is:

scheduled task = “run at this time”
monitoring task = “check periodically and tell me if something changed”
event-triggered task = “run when this supported app event happens”

What changed on August 25?

ChatGPT already supported one-time tasks, recurring schedules, and monitoring tasks. The August 25 release adds a different trigger mechanism for supported connected apps.

Instead of asking:

Check my inbox every hour and tell me when a registration email arrives.

an eligible user can now ask Work to respond to the arrival of the email itself.

Likewise, instead of polling Slack or GitHub on a schedule, the task can be tied to a supported new-channel-message or pull-request event.

That distinction matters for three reasons:

1. Less unnecessary checking. A task does not need to run repeatedly when nothing happened.
2. Lower delay. The workflow can begin when the event is delivered rather than waiting for the next scheduled check.
3. Clearer automation design. The trigger can match the actual business event: message arrived, channel changed, pull request changed.

OpenAI still calls these scheduled tasks in the product because they are managed from the same Scheduled area, but their trigger is an event rather than a clock.

What can trigger a task right now?

OpenAI currently documents three app families.

Gmail: new-message triggers

A Gmail-triggered task can respond when a new message arrives. OpenAI says Gmail tasks can also filter by sender or subject.

That makes the feature useful for workflows such as:

• summarize messages from a specific vendor;
• flag a registration or booking confirmation;
• prepare next steps when a particular customer replies;
• extract action items from messages matching a known subject pattern.

The safest design is to make the trigger narrow.

Instead of:

Summarize every email I receive.

prefer something like:

When a new email arrives from [approved sender/domain] with [subject condition], summarize the key decision, deadline, and any action requested. Do not send a reply automatically.

That reduces both noise and the amount of mailbox content passed into an unattended workflow.

Slack: new messages in monitored channels

Slack-triggered tasks can respond to new channel messages.

OpenAI says @ChatGPT must be added to each Slack channel the task monitors. That is an important boundary: connecting Slack to ChatGPT does not automatically mean every channel becomes an event source.

A practical Slack use might be:

• when feedback appears in #product-feedback, summarize the request and classify it;
• when a deployment channel reports a failure, create a short diagnostic brief;
• when a specific project channel receives a decision, extract owner, deadline, and unresolved questions.

Avoid broad triggers that make every casual message launch a long AI job. The event should be specific enough that a human would actually care when it happens.

GitHub: supported pull-request activity

GitHub-triggered tasks can respond to supported pull-request activity in an authorized github.com repository.

That makes a different class of workflow possible:

• review what changed after a pull request is updated;
• summarize a new set of changes for a reviewer;
• compare a pull-request update with a stated requirement;
• prepare a checklist when a PR reaches a relevant state.

OpenAI’s current help page says supported pull request activity rather than promising every GitHub webhook event. That wording matters. Do not assume pushes, issues, releases, discussions, deployments, repository settings, or every PR sub-event are all available until the task creation UI explicitly offers them.

Webhook task vs monitoring task: which should you use?

Event triggers are not automatically better.

The rule is simple:

Use an event trigger when one supported external event is the reason the work should start. Use a schedule when time itself is the reason. Use monitoring when the system has to look for a condition.

That prevents a common automation mistake: turning every workflow into hourly polling just because hourly polling was previously the only available option.

Which ChatGPT plans can use event-triggered tasks?

OpenAI’s current Scheduled Tasks documentation lists event-triggered tasks for:

• Plus
• Pro
• Business
• Enterprise
• Edu
• eligible ChatGPT for Healthcare workspaces

They are not available to Free or Go users.

OpenAI also says event-triggered tasks require ChatGPT Work and the relevant connected app. Availability can still depend on account rollout, app availability, region, and workspace controls.

For managed workspaces, another layer applies: Enterprise, Edu, and ChatGPT for Healthcare admins must enable event-triggered scheduled tasks before members can create them.

OpenAI specifically warns that ChatGPT for Healthcare event-triggered tasks are not covered under a Business Associate Agreement (BAA) and must not be used to transmit, store, or process protected health information.

Active-task limits still apply

OpenAI currently lists these active-task limits:

Event-triggered tasks live in the same task system, so capacity still matters. If the account hits its active-task limit, another task may need to be paused, deleted, or completed before a new one can run.

OpenAI does not publish a separate “per webhook” consumer fee in the Scheduled Tasks help page. Task/model usage still depends on the account plan, model, workload, and workspace billing arrangement.

Permissions do not disappear just because the task is automatic

This is the most important practical part of the release.

An event-triggered task uses the permissions of the connected app and account. A shared task does not magically inherit the creator’s Gmail, Slack, or GitHub access.

OpenAI says that when someone schedules a shared webhook-triggered task, they need:

• access to Work;
• their own supported app connection;
• the relevant app or workspace permissions;
• available task capacity.

That is a good security property because the shared instruction and the underlying authorization remain separate.

Read and action permissions are different

A task may be able to read an event and prepare output without being allowed to perform a consequential external action.

OpenAI says actions that require approval can pause the task until a person reviews them.

For automation design, separate the workflow into two stages:

1. Event processing: read, summarize, classify, compare, draft.
2. Consequential action: send, post, merge, update, delete, or modify an external system.

The first stage is often safe to run unattended. The second deserves a much higher bar.

A practical approval framework

A useful way to decide what should run automatically is to classify outputs by reversibility.

Green: usually safe to automate

• summarize a new message;
• extract deadlines or action items;
• classify a request;
• compare a PR update with a checklist;
• create a private draft;
• prepare a recommendation for review.

Yellow: automate preparation, keep human approval

• draft an email reply;
• draft a Slack response;
• prepare a GitHub comment;
• propose task assignments;
• propose changes to an issue or ticket;
• recommend whether a PR needs another review.

Red: keep explicit approval or existing control gates

• send customer-facing commitments;
• approve payments or refunds;
• merge code into a protected branch;
• modify production configuration;
• delete data;
• change access permissions;
• make legal, medical, employment, or financial decisions.

The point of event-triggered tasks is to remove waiting and manual triage—not to erase accountability.

Three automations that are genuinely better as webhooks

1. Important-email triage

Trigger: New Gmail message from a specified sender or matching a defined subject.
Task: Extract the request, deadline, attachments mentioned, and unanswered questions.
Output: Private summary plus a draft response.
Approval: Human reviews before anything is sent.

Why webhook is better: the workflow only runs when the relevant message actually arrives.

2. Product-feedback intake from Slack

Trigger: New message in an approved feedback channel.
Task: Classify the message as bug / feature request / confusion / praise / other, preserve the original wording, and extract reproduction details if stated.
Output: Structured internal note.
Approval: Human decides whether it becomes a ticket or roadmap item.

Why webhook is better: feedback gets processed at intake without requiring an hourly scan of the whole channel.

3. Pull-request change brief

Trigger: Supported update to an authorized pull request.
Task: Explain what changed since the previous version, which files or requirements are affected, and which checks still need attention.
Output: Reviewer brief.
Approval: Existing GitHub review, CI, branch protection, and merge policies remain authoritative.

Why webhook is better: the brief is prepared when the PR changes rather than on a fixed review schedule.

Five mistakes to avoid

1. Making the trigger broader than the decision

“Every Gmail message” or “every Slack message” can turn an automation into noise. Filter as close as possible to the event that actually matters.

2. Letting the task infer missing authority

A message saying “please refund this” does not mean the AI has authority to issue a refund. The event can trigger analysis without granting permission to act.

3. Treating a shared task as shared credentials

Recipients schedule their own copy and use their own app connection and permissions. Design the task so it still makes sense when different people have different access.

4. Assuming every GitHub event is supported

The current documentation specifically refers to supported pull-request activity. Verify the available trigger before designing an automation around an issue, push, release, or deployment event.

5. Forgetting the failure path

An unattended task can pause because it needs approval, authorization has changed, the associated chat is deleted, or another action is required. The Scheduled page still needs occasional review.

Where can these tasks be created?

OpenAI says users can create and update event-triggered tasks on web, iOS, and Android when the feature is available.

The current help page says the desktop app can display existing event-triggered tasks but does not support creating or editing their trigger conditions. If the trigger controls are missing on desktop, use the web or a supported mobile app.

Tasks are managed from Scheduled, where they can be reviewed, edited, paused, resumed, shared, or deleted.

What should teams watch next?

The feature is useful now, but the most interesting unanswered questions are about breadth and governance.

More trigger types

Gmail, Slack, and GitHub are a strong first set, but the real platform shift would come if more connected apps receive narrowly defined event triggers.

More granular event controls

GitHub’s current wording—“supported pull request activity”—leaves room for more explicit event selection over time. Granular trigger conditions reduce unnecessary runs and make permissions easier to reason about.

Better failure and audit visibility

As more work becomes unattended, teams will care about clear histories showing what triggered a run, what data the task accessed, what action it proposed, what required approval, and why a run paused or failed.

Shared workflow templates

OpenAI now lets users share scheduled and event-triggered tasks so recipients can inspect the instructions and create independent copies. That could turn useful internal automations into reusable workflow templates without sharing the creator’s credentials.

Conclusion

ChatGPT’s new webhook-based scheduled tasks are a meaningful change because they replace a crude pattern—“check every hour”—with a cleaner one: “run when the relevant event happens.”

The feature is currently narrow rather than universal. It works with supported Gmail messages, Slack channel messages, and GitHub pull-request activity, and it requires an eligible plan, Work access, a connected app, and the necessary permissions.

The best first use is not fully autonomous external action. It is event-driven triage: summarize the email, classify the Slack message, review the PR change, prepare the draft, and stop before the irreversible step.

That is where webhooks provide immediate value without turning a useful assistant into an unreviewed decision-maker.

Sources

Checked August 27, 2026:

• OpenAI Help Center — Scheduled tasks in ChatGPT
• OpenAI Help Center — ChatGPT release notes, August 25, 2026
• OpenAI Help Center — ChatGPT Business release notes, August 25, 2026
• OpenAI Help Center — ChatGPT Enterprise & Edu release notes
• OpenAI — Business pricing