Monitoring & Logs

Why this matters

In most tools, what you see while developing and what you see in production are two completely different systems — a debugger locally, a separate log aggregator in production, learned separately. In Fimaflow they're the same format: a production incident reads exactly like a failed test run in the builder, because it's produced by the same execution engine. Nothing new to learn when something breaks at 2am.

Live request monitoring

Every request handled by a deployed workflow — endpoint, status code, response time — is tracked from the moment Runtime receives it. Open a deployment's monitoring tab to see traffic as it happens: which endpoints get hit, how often they fail, and how their latency trends over time.

Production logs

A production run produces the exact node-by-node log format you already know from Debugging — including automatic masking of anything that looks like a credential:

1. API Endpoint   ✓  received { "sku": "TSHIRT-M", "qty": 2 }
2. Validation     ✓  body matches schema
3. SQL            ✗  connection failed: DATABASE_URL is not set
4. Response       —  never ran

Request failed at step 3 — 502 returned to caller

Filter by workflow, status, or time range to narrow down a spike instead of scrolling a flat stream. Logs are retained per your plan's log retention window, visible from Settings → Execution.

Error tracking

Failed requests are grouped by the node and error that caused them, not listed one by one — so a spike from one recurring failure (a downstream API down, an expired credential) shows up as one entry with a count, not a hundred identical log lines to scroll past.

Working alongside an AI assistant

Anything visible here is also readable by an assistant connected through MCP Server — asking "why did my API return 500s last night" pulls from the same log data this page shows.