🛠️ Build: publish a scheduled automation

Let’s publish a simple but real automation: every day at 8 a.m., it fetches some information (for example, a news summary, the day’s weather, or pending requests from a system) and notifies you — by email or message. The goal here isn’t the automation itself; it’s the entire publishing process, which applies to any automation you build in the future.

You won’t write code by hand. Claude Code writes it; you read what it proposes (remember plan mode, module 4.5?), approve, test, and publish. Your job is to guide and review — just as a manager approves an employee’s work before it goes out the door.

New here? Trigger.dev it’s the execution platform this course uses: you (or rather, the agent) write the task’s code, deliver it to the platform through a repository, and it takes care of running it at the right time, with retries and a built-in queue (module 4.5). You don’t need to know how Trigger.dev works under the hood—you just need to know how to request the right task and read what it returns.

Open a terminal in your project folder (module 0.3) and use plan mode before asking it to do the actual task—that way, you can review the design (search separately from writing, as in module 4.5) before the code is written.

Objective: ask Claude Code to create a scheduled task that retrieves a simple piece of data and notifies you by email, following the best practices from the previous modules.

Quero uma automação agendada usando Trigger.dev, escrita em TypeScript.
Ela deve:
1. Rodar todo dia às 08:00 (horário de ).
2. Buscar  — essa etapa não grava nada, só lê.
3. Se a busca der certo, montar um e-mail resumido e enviar para
    — essa é uma etapa separada
   da busca, como aprendi no módulo 4.5.
4. Usar retentativa automática (3 tentativas) só na etapa de busca,
   já que repetir a busca é seguro.

Antes de escrever o código, me mostre o plano das tasks separadas e onde
ficam as variáveis de ambiente (chaves de API) que vou precisar cadastrar.

How to verify: Claude Code should respond with a plan listing at least 2 tasks (search and send), the names of the required environment variables (without actual values), and the schedule in a time format. Only after that should you approve writing the code.

New here? Dev (from "development") is the test environment — a copy of the automation that runs separately from the real version that users (or you yourself, day to day) rely on, called production. That's the subject of module 4.3: two "worlds" so you can break things without worry in the test one.

After Claude Code finishes writing the task, run it locally in Trigger.dev's development mode, which runs the task right away without waiting for the scheduled time—so you can see the result (or the error) in seconds, not the next day.

Objective: run the task manually in development mode to confirm it works before actually publishing it.

# dentro da pasta do projeto, com o CLI do Trigger.dev instalado
npx trigger.dev@latest dev

# noutro terminal, dispare a task manualmente (sem esperar o cron)
npx trigger.dev@latest test 

How to verify: in the terminal where you ran it dev, you should see a sequence of lines showing the task starting, fetching the data, and finishing successfully (usually in green). If you see red, that’s an error—go back to Claude Code, paste the error message, and ask it to investigate before continuing.

New here? One environment variable is a secret value (an API key, a password) that the automation uses but is never written into the code—as module 4.4 explained, the local file with these values is never uploaded to the repository. Instead, you enter them manually in the platform’s dashboard.

Notice that you enter the keys twice: once in the dev environment (just for testing) and once in production—they’re separate boxes. This prevents a test key (less powerful and cheaper) from being used accidentally in the real environment.

Caption: the local file never goes to the repository; you enter the same key names, with different values, directly in the dev and production dashboards — each environment has its own isolated set.

New here? Deploy is the act of publishing: taking code you've already tested in dev and putting it into production, where it runs for real and is available 24 hours a day. Cron it’s the standard way to write “what time to repeat”— a compact format like “every day at 8 a.m.” translated into symbols, but Claude Code writes it for you based on what you ask for in Portuguese.

Deploy takes the code from your repository to the platform, which then runs it on its own on the defined schedule —without your laptop needing to be on (the topic of module 4.1).

Objective: publish the tested task to production, after you’ve already added the production secrets in the dashboard.

# confirma que está na branch principal e tudo commitado
git status

# envia o código pro repositório remoto (GitHub)
git push origin main

# publica a versão de produção na plataforma
npx trigger.dev@latest deploy --env production

How to verify: The deploy command finishes by displaying a success message with the name of the published task. Then, open the platform dashboard (trigger.dev, on your project tab) and confirm that the task appears listed as “active” with the correct schedule (e.g., “every day at 08:00”).

A published deploy isn’t the end—it’s the start of a check-in routine. The next day (or a few hours later, depending on the scheduled time), go back to the dashboard (also called dashboard — the screen where the platform shows everything that ran) and confirm the run appeared with a success status.

This habit of checking — without needing to understand the code behind it — is exactly what the next module, the last in this track, is about: reading the execution dashboard and, when something fails, finding the reason by reading the log, not the code.