📺 The runs dashboard
New here? One dashboard (or dashboard) is the screen where the execution platform shows everything that ran: each time your automation runs, a new line appears—with the date, time, and a status (success or failure). It’s the “bank statement” for your automation: you don’t need to understand how the bank processes things behind the scenes; you just need to see whether everything checked out.
In the Trigger.dev dashboard (the platform used in module 4.6), each run becomes a clickable row. Clicking it opens the details — including the log, which is the subject of the next section.
Caption: on the left, the list of runs with color-coded statuses. On the right, what appears when you click a failed run—the log, line by line, showing exactly where and why it got stuck.
📜 What a log really is
New here? One log it’s the list of events the automation recorded while it was running—like a logbook. Each line records “what happened” and “when.” It isn’t code: it’s plain text, in chronological order, telling the story of what the automation tried to do.
You don’t need to know how to read TypeScript. You need to know how to read the log. It's the most important sentence in this module. The log tells the story in Portuguese (or in clear messages), even when the code behind it is technical—because whoever wrote the task (Claude Code, following your instructions) usually leaves readable messages at each important step.
💡 Main Concept
- •Each log line includes: time + what happened.
- •Normal lines show the progress (“searching...”, “sending...”).
- •Error lines (usually highlighted in red or marked with the word “ERROR”) indicate where it got stuck.
🔴 Finding the red line
When a run shows a failure status in the dashboard, the process is always the same: click it, open the log, and scroll down until you find the first line marked as an error. You don't need to read everything with equal care — the normal lines just confirm that "so far, so good"; what matters is where the story changes course.
Remember module 4.5? If the automation was designed well, with retries, you’ll see a few attempts recorded in the log before the final error—that’s normal and doesn’t mean everything is broken; it means the system tried to recover on its own and couldn’t that time.
✓ Efficient log reading
- ✓Goes straight to the first line marked as an error
- ✓Read the surrounding message to understand the context (what it was trying to do)
- ✓Copy the entire error line without trying to summarize it from memory
✗ Getting lost in the log
- ✗Tries to read line by line from the beginning, gets tired, and gives up
- ✗You see a technical term and think you need to understand code to keep going
- ✗Describe the memory error to Claude Code without pasting the exact text
💡 Practical Tip
Most execution dashboards have a "copy log" button or let you select the text directly. Use it — copying the exact excerpt is much more effective than trying to summarize the error from memory.
🤝 Taking the error back to the agent
Found the red line? You don't have to figure it out alone. Go back to Claude Code, paste the log excerpt (with a few lines of context before and after), and ask it to investigate — it reads code naturally and translates the problem into Portuguese for you.
Objective: ask Claude Code to investigate a real failure, using the log copied from the dashboard as evidence—without needing to understand the technical error first.
Minha automação "" falhou na execução de
. Colei abaixo o trecho
do log a partir de onde os erros aparecem. Me explique, em português
simples, o que provavelmente deu errado e sugira uma correção. Se for
algo relacionado a uma variável de ambiente/chave de API, me diga qual
delas conferir no painel — sem eu precisar mexer no código.
--- log colado ---
--- fim do log --- How to verify: the agent’s answer should point to a likely cause in plain language (e.g., “the API key seems to be wrong or expired” or “the external service took longer than the timeout”) and a concrete action — fix the code, register a new key, or increase a wait time. If the answer is vague, ask: “point to the exact line in the log that led you to that conclusion.”
⚠️ Attention
Before pasting a log, check that it doesn’t accidentally contain a real API key—some authentication errors show part of the key used. If it does, delete that part before pasting the log anywhere, including into a conversation with the agent.
🔄 The habit of checking
Observability isn’t a one-time event—it’s a habit. An automation that’s been published with no one checking the dashboard from time to time may have been failing for days without your knowledge.
The good news: you don’t need to check manually every day. Most platforms let you set up an alert (by email or message) that automatically notifies you when a run fails—so the dashboard only needs your attention when something actually calls for it.
First week: check every day
After publishing a new automation, check the dashboard daily until you're confident it's stable.
Next: set up an alert and relax
Ask Claude Code to configure an automatic failure alert — that way, you only check when you need to.
When the alert arrives: logs first, code second
Follow the process in topics 1 through 4 — dashboard, log, red line, agent.
🏁 Wrapping up Track 4
You’ve gone through the whole process: why local isn’t enough (4.1), the code → repository → cloud pipeline (4.2), the separation between testing and production (4.3), how to protect secrets (4.4), why to break everything into small tasks with retries (4.5), published a real automation (4.6), and now you know how to read the dashboard when something fails (4.7).
This is the complete set of skills you need to take any of your automations off your laptop and get them running for real, on their own, safely. The next track changes topics: how to give your agent the ability to see screens and build visual interfaces.
🎯 Main Concept
- •The panel shows the result. The log shows the history. You don’t need TypeScript to read either one.
- •Isolated failure + retry + clear log = reliable automation even without constant supervision.
Quick check (optional): Your automation failed. What is the right first step?