TL;DR
- Cloud Run Jobs is a good default for a containerised daily agent on Google Cloud.
- Amazon ECS with EventBridge Scheduler is the natural choice for a team already operating AWS containers and permissions.
- Azure Container Apps Jobs fits finite scheduled or queue-driven work in an Azure environment.
- Modal is attractive for a Python team that wants deployed functions, cron scheduling and managed compute without assembling a cloud container stack.
- Grok Bot is a different purchase: a managed agent with a persistent computer, application access and routines, rather than a runtime for your own container.
For most daily GTM research, run the job, save the result and exit. Choose the cloud your team already operates. On a small batch, model calls, data services and maintenance usually cost more than the scheduled compute.
Compare the execution models
| Option | What you deploy or configure | Schedule | Best fit | Principal trade-off |
|---|---|---|---|---|
| Cloud Run Jobs | A container that completes and exits | Cloud Scheduler invokes the job | Google Cloud team with a packaged agent | Application state and per-item recovery remain yours |
| ECS scheduled task | ECS task definition on Fargate or another capacity option | EventBridge Scheduler | Existing AWS infrastructure | Task launch success is separate from task completion |
| Azure Container Apps Jobs | Finite container job | Manual, cron or event-driven execution | Azure identity and queue-based operations | Scheduled cron is evaluated in UTC |
| Modal | Deployed function and its dependencies | Cron with an optional time zone, or an interval | Python-led build with little infrastructure overhead | Its function, resource and deployment model governs execution |
| Grok Bot | Instructions, skills, connectors and routines | Managed scheduled routines | A user wanting work across real apps without building a runtime | Plan usage and shared account computer replace explicit CPU sizing |
The first four run code you own. Grok Bot supplies the agent itself. An inexpensive container runtime is not an equivalent substitute for an agent that navigates applications, just as a managed agent subscription is not a published allowance of CPU-hours.
The five options
1. Cloud Run Jobs: best for a Google Cloud container
Cloud Run Jobs runs container tasks to completion. Use it for a daily research batch, enrichment worker or report builder whose process can exit after saving the result. Cloud Scheduler supplies the recurring trigger and its selected time zone; a service account authorises invocation. Create jobs and schedule jobs.
For the current Iowa pricing basis, Jobs CPU is $0.000018 per vCPU-second and memory $0.000002 per GiB-second. Monthly free allowances are 240,000 vCPU-seconds and 450,000 GiB-seconds, aggregated by billing account. These are Jobs rates, rather than request-billed web-service rates. Networking and other services are separate. Cloud Run pricing. Cloud Scheduler charges $0.10 per billable job per 31 days, rather than per execution, with a small free allowance. Scheduler pricing.
Choose it if Google Cloud is already your operating environment. It is a weaker fit for a nontechnical owner seeking a ready-to-use agent: Google starts the container, while your application supplies the research logic and business completion record.
2. ECS with EventBridge Scheduler: best for an AWS team
EventBridge Scheduler can invoke ECS RunTask on one-time, rate or cron schedules, including a selected time zone. The configuration selects the task definition, capacity, networking and execution role. Scheduler retries and its dead-letter queue concern failed delivery to the target; a successfully launched task can still fail inside its research code. ECS scheduling documentation.
For Linux/x86 Fargate in US East/Northern Virginia, AWS's current example rates are $0.000011244 per vCPU-second and $0.000001235 per GB-second of memory. Billing starts with downloading the container image and continues until termination, with a one-minute minimum. Fargate pricing. EventBridge Scheduler includes 14 million monthly invocations before its $1-per-million charge; the compute and surrounding services remain separate. EventBridge pricing.
Choose this for an established AWS team. Avoid building a new AWS stack solely to shave a few cents from a daily task. Logs, outbound connectivity, container storage and application state can matter more than the task's CPU bill.
3. Azure Container Apps Jobs: best for finite Azure work
Azure supports manual, scheduled and event-driven jobs. Scheduled jobs use five-field cron expressions evaluated in UTC. Event-driven execution can use supported scalers for queues and other sources; that is useful when account items arrive throughout the day rather than in one daily batch. Container Apps Jobs documentation.
On the Consumption plan, compute is charged by allocated CPU and memory time. Its published monthly allowance is 180,000 vCPU-seconds and 360,000 GiB-seconds per subscription. The relevant buying basis is the region's active compute rates after that grant; this comparison does not invent a dollar rate from a pricing page that displays unpopulated regional figures. Azure Container Apps pricing.
Choose Azure when its identity, queues and monitoring already support the application. It is less useful as a new standalone platform for someone wanting to describe an agent in natural language. The job service executes the container; it does not supply the complete GTM process.
4. Modal: best for a Python-owned scheduled function
Modal attaches scheduling to deployed functions. A Cron schedule can specify a time zone. Its Period schedule is relative to deployment and resets when redeployed, so use Cron for a fixed daily business time. Modal scheduling.
Standard function pricing lists $0.0000131 per physical CPU core-second, described as two vCPUs equivalent, and $0.00000222 per GiB-second of memory. Starter has no fixed subscription, $30 in monthly compute credits, three seats, five deployed crons and one-day log retention. Team is $250/month plus compute, with $100 monthly compute credit, unlimited scheduled functions and 30-day logs. These are function rates; Sandbox and Notebook rates are higher and should not be substituted into a scheduled-function budget. Modal pricing.
Choose Modal for a small Python team that values a simple deployment path. A developer still owns the workflow and external state. Do not buy Team just because a single daily cron uses paid APIs; upgrade when collaboration, retention or platform limits justify it.
5. Grok Bot: best for managed app-based work
Grok Bot provides named agents with a persistent cloud computer, browser, filesystem and terminal. Work can continue with the user's device closed. Bots in the same account share files, browser sessions and application logins; separate Bot names are not separate customer environments. Grok Bot overview.
A skill stores the workflow instructions, while a routine determines when an owning Bot runs them. Its routine controls include schedule editing, pause and recent run history. Skills and routines.
Access is included with paid individual Cursor plans and Cursor Teams, or eligible individual linked subscriptions. Cursor Pro's published base is $20/month; Grok Bot usage follows weekly plan allowances, with higher tiers offering more. That $20 is an access basis, not a guarantee that a 1,000-account batch fits. Grok Bot plans and Cursor pricing documentation.
Choose it for a user who wants an agent to work across applications and return a reviewable report. For explicit resource sizing, deployed code and repeatable per-record processing, choose one of the code runtimes instead.
A daily account-research job
Consider an illustrative daily job at 08:00 Africa/Harare. It reads 50 queued accounts, retrieves the relevant company and careers pages, prepares source-backed briefs, saves them to the database and produces a summary for a sales operator. It drafts account recommendations without sending outreach.
The code-runtime implementation follows the same steps on all four platforms:
- Claim today's run key and pending account items in the external store. If another execution owns the live run, exit without duplicating work.
- Retrieve and match the company, preserving source URLs and retrieval times.
- Generate the brief only after useful evidence is available.
- Save each completed account immediately, rather than waiting until all 50 finish.
- Record completed, rejected and failed item counts, then exit.
Use the schedule's time-zone setting on Cloud Scheduler, EventBridge or Modal Cron. For Azure's UTC cron, 08:00 Harare is 06:00 UTC, expressed as 0 6 * * *. A failed account goes into the next recovery batch while successful accounts stay completed.
In Grok Bot, the analogous routine instructs the owning Bot to read the account list, prepare briefs and leave the summary in its conversation or chosen output location. It manages the application work, so the buyer does not choose a 1-vCPU container. That convenience is the reason to buy it; it should not be assessed as merely another container scheduler.
The signal-based outbound playbook gives the account-selection and messaging framework for using the saved briefs.
The monthly operating budget
Assume 30 daily executions lasting 20 minutes, plus three recovery executions of the same length. At one vCPU and 2 GiB memory, the workload is 39,600 vCPU-seconds and 79,200 GiB-seconds: 11 billed runtime hours. Treat those durations as inclusive of startup and retries. They are planning assumptions, not observed provider performance.
| Runtime | Calculation before credits or grants | Compute for this workload |
|---|---|---|
| Cloud Run Jobs, Iowa | 39,600 × $0.000018 + 79,200 × $0.000002 | $0.87 gross; covered if the account's free allowance remains available |
| Fargate Linux/x86, Northern Virginia | 39,600 × $0.000011244 + 79,200 × $0.000001235 | About $0.54; Scheduler invocations fit its free allowance |
| Azure Consumption Jobs | Both resource totals are below the published monthly grants | $0 compute when those subscription grants are available; active regional rates apply after they are exhausted |
| Modal standard functions | Assume 0.5 physical core equivalent: 39,600 × (0.5 × $0.0000131 + 2 × $0.00000222) | About $0.44 gross; covered by Starter's $30 monthly compute credit |
Modal's allocation is a planning equivalent for this comparison, rather than a hardware throughput guarantee. Choosing more CPU, a specific priced region or non-preemptible execution changes its bill. The four rows exclude logs, state storage, outbound networking, model calls and external data tools. A database or networking setup can therefore cost much more than the sub-dollar batch compute.
For a practical total, assume $20 of model calls, $25 of data API usage and $10 of state/log storage per month. Add two maintenance hours at $75/hour: $150. On the Fargate example, that gives $205.54, before any separate networking bill. With 1,500 account inputs and 1,200 usable briefs, it is about $0.17 per usable brief. Cloud Run or Modal's available credits save less than a dollar in this scenario; changing platforms is unlikely to repay even one migration hour.
Suppose setup takes 12 developer hours at $75/hour: $900 once. Avoiding three minutes of manual preparation per input saves 75 hours monthly, or $3,750 at an assumed $50 operator rate. Against the illustrated $205.54 operating cost, that leaves about $3,544 before setup. The value comes from usable briefs and saved work, not from labelling the process “always on.”
For Grok Bot, use its eligible subscription and weekly usage basis instead of adding an invented CPU charge. An existing subscriber may have no new base subscription to buy, but external data services can still cost money. Choose it when managed application work reduces the build effort sufficiently to justify that different control model.
Persistent state and safe recovery
Store the business queue and results outside a disposable process. A record should say which account, date and source set it represents, which steps finished and where the result lives. The next execution reads that state rather than replaying every account.
A scheduler's successful invocation is not the final business outcome. Watch for a run that launches but produces no completed items, a task that exits nonzero, and a report that contains the wrong company. Keep errors tied to the run ID and account ID so an operator can retry the right item.
For any later CRM write, use the known record ID and read back after an uncertain response. A timeout may follow a successful remote write; blindly creating the same contact again is avoidable. Do not repeat already completed model and data calls simply because the final summary failed.
Persist credentials through the runtime's secret-management route, separate from the research payload. For a managed account computer, keep client boundaries aligned with its shared sessions and files. Durable memory helps an agent resume context; the external result ledger establishes what actually completed.
Which option to buy
Use Cloud Run Jobs, ECS/Fargate or Azure Container Apps Jobs in the cloud your team already knows. Their scheduled compute is inexpensive for a small finite batch. Existing identity, logging and maintenance expertise are better reasons to choose than the cents in the worked table.
Use Modal for a Python-first developer who wants the shortest route to a deployed scheduled function. Starter suits a small number of jobs; additional collaboration and retention can justify Team.
Use Grok Bot when the requirement is managed work across apps with persistent context and a conversational handoff. For an exact daily data-processing pipeline, retain the code-runtime route and explicit state. Either choice should return a usable result and a clear completion record.
FAQ
Does a daily agent need a permanent server?
No. Start the job, process its queue, save outputs and exit. Use a continuously running service when the application actually needs live connections or request handling.
Are free compute grants enough to make the whole agent free?
No. Model calls, paid data, storage, networking and operating time are separate. The worked workload fits several compute allowances, but that does not remove those costs.
Does scheduler retry mean the account job will finish?
No. It can recover a failed trigger, while the container still needs per-account progress and recovery. Inspect the stored outcomes as well as the launch status.
Which platform is best for a nontechnical operator?
Grok Bot is the managed agent option in this shortlist. The other four are best when a developer will build and maintain the scheduled code.
