ChatGPT Scheduled Tasks can run a one-time or recurring instruction at a chosen time or interval. Event-triggered tasks respond to supported activity in connected apps. The distinction is practical: “Prepare a meeting brief every weekday” is schedule-based, while “Summarize a qualifying new Slack message” depends on a source event.
These features can support bounded research, summaries, reminders, drafts, and other reviewable work. They are not a general-purpose automation platform with a user-managed webhook endpoint, universal event payload, or published task-run API. Availability, app access, permissions, approvals, and workspace settings determine what a particular account can do. Check the current OpenAI Scheduled Tasks documentation before designing a process around the feature.
Use a clock schedule when the question becomes relevant at a known time, such as “Every weekday, prepare today’s meeting brief.” Use an event trigger when the question depends on a qualifying source event, such as a new message or supported pull-request activity. Connecting an app alone does not create a trigger or expose every event.
What ChatGPT Scheduled Tasks do
A scheduled task runs at a specified time or interval. An event-triggered task runs when qualifying activity occurs in a supported connected app. OpenAI describes event-triggered tasks as webhook-based tasks configured in ChatGPT Work. That description does not give users a general-purpose webhook URL, arbitrary event payloads, or access to every event in a connected app.
Choose the task type based on the moment the work becomes relevant. A recurring weekday brief needs a schedule. A summary that should begin after a qualifying new message needs an event trigger. If the source has a documented event trigger, do not imitate it with frequent polling unless the account and source support the required schedule.
Check availability and limits before designing the task
OpenAI currently documents scheduled tasks for eligible Free, Go, Plus, Pro, Business, Enterprise, Edu, and ChatGPT for Healthcare users. Plan names do not guarantee identical access because account, app, region, and workspace controls can affect availability.
| Plan | Active tasks | Plan | Active tasks |
|---|---|---|---|
| Free | 3 | Go | 3 |
| Plus | 5 | Business | 10 |
| Edu | 10 | Pro | 15 |
| Enterprise | 15 | ChatGPT for Healthcare | Workspace-dependent |
Free users can create a one-time task or a recurring task no more than once per day, using flexible windows such as morning, afternoon, or night. Eligible paid plans support exact delivery times and recurring schedules as often as hourly, subject to account limits and task conditions.
Event-triggered tasks are available to eligible Plus, Pro, Business, Enterprise, and Edu users and eligible ChatGPT for Healthcare workspaces. Free and Go users cannot create them. Enterprise, Edu, and ChatGPT for Healthcare administrators must enable the feature, and it is unavailable in FedRAMP workspaces.
OpenAI documents an aggregate limit of up to 30 event-triggered runs per hour and 720 per day across a user’s event-triggered tasks. These are not per-task guarantees. Multiple source events may be grouped into one run, and other account conditions can affect execution.
Check the Scheduled interface and workspace settings before committing to a workflow. Confirm the intended app, trigger, action, and recurrence rather than inferring access from a plan name.
Create and refine a scheduled task
Open ChatGPT and look for Scheduled when it is available for the account. A task can be created from Scheduled or by asking ChatGPT to perform an action at a specified time or interval. OpenAI recommends running and refining the instruction in a normal chat before scheduling it.
A useful instruction identifies the information sources, date range, purpose, output sections, source-link requirement, behavior when information is missing, and whether the task must remain read-only. If the task will produce a draft or proposed action, say so explicitly.
OpenAI’s meeting-brief walkthrough demonstrates a two-stage process. First, ChatGPT uses connected Gmail and Google Calendar to prepare and refine a brief. Then the same task is scheduled for weekdays. The walkthrough is an instructional example, not a production template with documented retries, structured validation, database writes, or deduplication.
For a practical first version, request each meeting’s objective, client priorities, decisions, risks, next steps, source links, and missing details. Keep the task read-only, confirm that the intended mailbox and calendar are connected, and inspect the first results before relying on the schedule.
Design event-triggered tasks around supported source events
In ChatGPT Work, connect the app, define the event, and review the task’s Trigger, Condition, and Prompt. Web and supported mobile apps are the documented surfaces for creating and editing event-triggered tasks. The desktop app may show existing tasks but does not support editing their trigger conditions.
- Gmail: OpenAI documents new-message triggers with filtering by sender or subject. Do not assume that arbitrary labels, attachments, thread states, or mailbox queries are supported.
- Slack: Add @ChatGPT to each monitored channel. New channel messages can trigger tasks, with filters for channel, sender, or thread. Direct messages, reactions, edits, and deletions do not trigger them. See OpenAI’s Slack guidance.
- GitHub: OpenAI documents supported pull-request activity in an authorized github.com repository. It does not enumerate every pull-request event, branch condition, or action.
Start with a bounded response such as a summary or draft. Where conditions are stable and binary, prefer explicit sender, channel, or repository filters over asking a model to infer permission. Let AI interpret content, while deterministic rules decide which sources and actions are allowed.
Connected-app permissions, user access, workspace settings, OAuth scopes, and approval requirements determine what a task can read or do. A connection is not unrestricted API access. OpenAI’s connected-app documentation explains that an action requiring approval can pause pending review.
A task execution is not necessarily one source event. OpenAI documents that multiple events may be grouped. Preserve each available source permalink or provider object ID alongside task and run context, and design downstream records so a grouped run cannot be mistaken for one message.
Turn examples into bounded operating workflows
The following designs use documented source capabilities but propose the operating controls around them. They are not vendor-provided templates. Each separates the source event, AI’s limited job, validation, destination, and exception owner.
| Trigger and input | AI job and output | Validation and destination | Fallback owner |
|---|---|---|---|
| Weekday meeting brief: connected Gmail and Google Calendar, then a recurring weekday schedule. | Prepare objective, priorities, decisions, risks, next steps, links, and missing details. | Confirm mailbox and calendar scope; inspect source links. Keep the result in the task for review. | Meeting owner checks unclear matches, missing access, or guessed details. |
| Gmail triage: new message matching a supported sender or subject condition. | Return a permitted category, urgency, rationale, source reference, suggested action, and review flag. | Require fields and allowed values. Keep the first version as a draft or task result; approve consequential changes. | Mailbox owner reviews incomplete messages or unsupported categories instead of sending or updating records. |
| Slack summary: new message in a monitored channel where ChatGPT has been added. | Extract an issue or decision, identify an owner only when supported, and draft a response. | Check channel access and source references. Review before posting and list messages represented in a grouped run. | Channel owner restores access or assigns the issue when membership or ownership is unclear. |
| GitHub summary: supported activity in an authorized repository. | Summarize the change or prepare review notes without deciding whether to merge. | Verify repository scope and source reference. Retain the result for reviewer inspection. | Repository owner checks authorization or uses the normal review process for unsupported activity. |
For a triage result, the following is an illustrative output contract, not an OpenAI schema:
{
"category": "billing_question",
"urgency": "normal",
"rationale": "The message asks about an upcoming invoice.",
"source_reference": "available message permalink or provider ID",
"recommended_action": "draft_reply",
"requires_human_review": true
}Validate required fields and allowed values before routing the result. A classification is not authorization. Check approved senders, channels, repositories, record IDs, and permitted actions with deterministic rules. If a consequential action is proposed, route it for approval rather than treating a generated draft as an executed action.
Use separate records for events, runs, and actions
If a workflow needs durable records, keep separate grains:
- Source observation: one record for each provider event, message, pull request, or other source object, using the provider ID or strongest available permalink.
- Task run: one record for each task execution attempt, including task ID, run context, processing status, and whether events were grouped.
- Generated action or decision: one record for each proposed or executed output associated with a source observation and task run.
- Citation: one record for each source link or object used in the result.
- Aggregate report: a daily or weekly summary linked to the underlying records, not a replacement for them.
For concurrent downstream writes, use a database-enforced unique key or transactional upsert. A lookup followed by create can race. An illustrative uniqueness key for one action record might be source_app + source_account + source_event_id + task_id + action_type. That key identifies an action at the source-event grain, not a run, citation, or aggregate report. If no stable source event ID is exposed, retain the strongest available permalink or object ID and mark duplicate suppression as best-effort.
Manage tasks, notifications, and exceptions
Use Scheduled to review, edit, pause, resume, or delete tasks. A task can also be opened from its conversation. If the associated chat is deleted, the task is paused rather than automatically deleted. Tasks do not support voice chats, GPTs, or locked chats, and tasks in a project cannot access files uploaded to or stored in that project.
Task notifications can be configured as Push, Email, or both under Settings > Notifications. Browser notifications also require browser permission. To receive mobile push notifications, create the task in a supported ChatGPT mobile app and grant notification permission there.
If a task appears not to have run, check task status and history, pending approval, connected-app authorization, workspace policy, and notification permissions separately. A paused task, an approval wait, an expired connection, and a notification failure are different problems and require different fixes.
Permissions, privacy, and when to use another automation design
Before enabling a task that reads or changes business data, verify the connected account, mailbox or channel, repository scope, requested action, approval behavior, and workspace policy. Keep the first version read-only or draft-only. Do not promise external auditability or reliable deduplication from native task history alone because OpenAI does not publish a general event payload schema, stable event-ID contract, task-run API schema, or general-purpose task-run export in the reviewed documentation.
Healthcare restriction: Event-triggered tasks in ChatGPT for Healthcare are off by default, are not covered by a BAA, and must not be used to transmit, store, or process PHI.
Native tasks suit bounded work using a supported schedule or source event with a clear owner. Consider Zapier automation services when a process needs broader app coverage, durable routing, or explicit orchestration, but verify each platform’s triggers, actions, permissions, limits, and deduplication behavior independently. For a larger AI-assisted operating workflow with defined review boundaries, see AI agent services.
Questions to check before launch
Why can I see Scheduled but not event-triggered tasks?
Event triggers require an eligible plan and supported workspace settings. Free and Go users cannot create them. Enterprise, Edu, and ChatGPT for Healthcare administrators must enable the feature, and app access or account configuration can also affect availability.
Why does a Slack task miss messages?
ChatGPT must be added with @ChatGPT to every monitored channel. The documented triggers cover new channel messages, not direct messages, reactions, edits, or deletions.
Why did I not receive a notification?
Check the task notification setting and the relevant browser or mobile permission. Push and email are configurable, so neither method should be assumed to be enabled by default.
- Confirm account eligibility, active-task capacity, workspace controls, and the intended recurrence.
- Verify the source account, channel or repository, supported trigger, and filter condition.
- Confirm connected-app permissions and whether the task may read, draft, send, create, update, or delete.
- Define required output fields, allowed values, source references, and missing-information behavior.
- Assign an owner for approvals, authorization failures, ambiguous events, unsupported triggers, and duplicates.
- Review initial runs and confirm notification permissions before relying on the workflow.
The safest starting point is a narrow task with a visible result, a clear source link, a deterministic validation step, and a named reviewer. Expand its permissions only after the first runs demonstrate that the trigger, output, and exception path behave as intended.