AI Agent Automation Platforms
How do I use TinyFish Workbench to debug failures with screenshots and run history?
6 min read
Most teams only realize their web agents are fragile once production breaks—forms change, logins fail, and you’re chasing screenshots from three different tools. TinyFish Workbench is built to flip that: one place to see every run, every step, every screenshot, and debug failures without touching browsers or logs directly.
Quick Answer: You use TinyFish Workbench to debug failures by drilling into run history, inspecting per-step status and metadata, and reviewing screenshots at each point of the workflow. That combination gives you a replayable timeline so you can pinpoint exactly where and why an agent failed, then refine instructions and re-run at production speed.
Frequently Asked Questions
How do I see failed runs and inspect them in TinyFish Workbench?
Short Answer: Open Workbench, filter for failed runs, then click into a run to see a step-by-step timeline with status, metadata, and screenshots for each action.
Expanded Explanation:
Workbench is your mission control for live execution. Every agent run is logged for 30 days with full observability—status, timestamps, structured outputs, and screenshots across the workflow. To debug, you don’t sift through raw logs or re-run blindly; you navigate the actual run history, then zoom into the failing step.
When you open a run, you get a chronological view of what the agent did: navigate, authenticate, fill forms, submit, extract, transact. Failures are clearly marked. You can click into any step to see inputs, responses, and what the page looked like at that moment. That’s usually enough to see if a selector changed, a form added a new field, or a login challenge appeared.
Key Takeaways:
- Workbench keeps 30 days of run history with full observability and screenshots.
- You debug by filtering for failed runs and drilling into each step in the execution timeline.
What is the process to debug a failure with screenshots and run history?
Short Answer: Locate the failed run, inspect the failing step and screenshot, compare to successful runs, then update your agent instructions and re-run.
Expanded Explanation:
Debugging in Workbench is a loop: observe → compare → adjust → re-run. You start with the failing run, identify the first step that changed state from success to error, and inspect the screenshot to see what the agent “saw.” Then you compare that behavior to past successful runs to confirm whether the site changed, a credential expired, or a CAPTCHAs/anti-bot system intervened.
Once you understand the failure mode, you modify your agent definition—usually clarifying navigation, updating target elements, or adjusting how you handle auth flows—then re-run against the same target. Because execution is serverless and parallel, you can test fixes quickly without managing any browser or proxy stack yourself.
Steps:
- Filter for failed runs in TinyFish Workbench and select a run with the relevant workflow or target site.
- Open the run timeline and identify the first step that shows an error or unexpected output; inspect its screenshot and metadata.
- Compare against a recent successful run, adjust agent instructions to match the current UI or flow, then re-run to validate the fix.
What’s the difference between using run history vs just screenshots to debug?
Short Answer: Screenshots show what happened visually at a single point; run history shows the entire execution context—order of actions, state changes, and structured outputs—which makes root-cause diagnosis faster and more reliable.
Expanded Explanation:
Screenshots alone tell you “what the page looked like,” but not why the agent made a specific decision or where upstream context went wrong. Run history adds the missing structure: the sequence of steps, the inputs sent (form fields, credentials), the responses extracted, and any error codes or timeouts.
In practice, that means you don’t misdiagnose a failure by staring at one screenshot. You can see if auth succeeded earlier, whether a previous form submission returned an error, or if navigation landed on a fallback page. The combination—timeline + screenshot—gives you a replayable narrative of the run instead of a folder of disconnected images.
Comparison Snapshot:
- Run History Only: Good for audit trails and understanding sequence, but you can miss subtle UI changes or anti-bot patterns without visuals.
- Screenshots Only: Good for human inspection of UI changes, but hard to map to specific actions, inputs, and outputs.
- Best for: Reliable debugging at production scale is the combination of run history and screenshots—TinyFish Workbench gives you both for each run.
How do I practically implement debugging in TinyFish Workbench for my workflows?
Short Answer: Treat Workbench as your primary debugging loop: use it to monitor runs, investigate failures, refine agent instructions, and validate fixes before scaling to hundreds of parallel agents.
Expanded Explanation:
Implementation looks like adding a new operational habit, not a new tool to babysit. Once your workflow is live—whether that’s carrier quoting, checkout totals, or portal extraction—you rely on Workbench to answer three questions: Did the agents run? Did they succeed? If not, why?
You can review runs on a cadence (daily, per-deploy, or after large target changes) and use the run timeline plus screenshots to preempt issues before they impact downstream consumers. Because TinyFish runs unattended in the cloud, you aren’t logging into a farm of VMs or headless browsers—you’re using a single UI and API to govern all runs.
What You Need:
- Access to TinyFish Workbench and API so you can view run history, screenshots, and structured outputs for your agents.
- Defined workflows and goals (e.g., “complete 53-step quote workflow across 20+ carriers”) so you know what success vs failure looks like when you inspect a run.
How does debugging with Workbench and screenshots translate into better results at scale?
Short Answer: Systematic debugging via run history and screenshots hardens your workflows, improves success rates, and preserves unit economics as you scale to thousands of operations.
Expanded Explanation:
When you’re running web data operations at scale—1,000+ simultaneous agents, multi-step auth flows, dynamic portals—failure isn’t a one-off annoyance; it’s a cost and reliability problem. Every broken run drives manual rework, stale decision-making, or both. Workbench is designed to turn failures into fast feedback: you see the break, understand it with visual and structured context, and push a fix that applies to every subsequent run.
Over time, this moves you from “AI trying to cope with everything” toward codified, deterministic execution on stable workflows. Your success rate climbs, your average run time shrinks, and your effective cost per step drops because agents don’t thrash on broken flows. For teams that “can’t afford to get it wrong”—pricing, availability, eligibility—this debugging loop is the difference between a demo and a production system.
Why It Matters:
- Higher reliability: Faster root-cause analysis boosts success rates across authenticated, multi-step workflows.
- Better economics: Fewer failed runs mean less manual cleanup, more predictable unit costs, and safer scaling to tens of thousands of operations per month.
Quick Recap
TinyFish Workbench gives you a single, production-grade pane of glass for debugging agent failures: 30 days of run history, per-step timelines, structured metadata, and screenshots across the entire workflow. You don’t manage browsers, proxies, or separate logging stacks—you just find the failed run, inspect the failing step, compare to successful history, adjust instructions, and re-run. That’s how you keep live, authenticated workflows accurate when the web keeps changing underneath you.