Inside Saasyio: how we built live workflow monitoring

The architecture behind real-time runs, retries and audit trails, and the trade-offs we made along the way.

What we wanted

Customers should be able to open a workflow and see what is happening right now: which step is running, what it received, what it returned and what happens next. When something breaks, they should see it before their team does.

Events, not logs

Early on we wrote logs. They were easy to produce and nearly impossible to build features on. We moved to a small, structured event for each step: started, succeeded, failed, retried, waiting for approval. Every feature in the monitoring view reads from the same stream.

• Each event carries the run, the step, a timestamp and a compact payload.

• Large inputs and outputs are stored separately and referenced by id.

• Sensitive values are masked before an event is written.

Making retries visible

Automatic retries are great until they hide a real problem. We show every attempt, the reason it failed and the delay before the next try. A step that succeeds on its third attempt is a signal worth seeing.

Live without being expensive

Streaming every event to every viewer does not scale. We push only the changes for the runs a person is currently watching, and fall back to a short polling interval when a connection drops. Most people never notice the difference; our infrastructure bill does.

If a feature cannot be explained from the event stream, we have the wrong events.

The audit log came almost free

Because every action is already an event, the audit log is a filtered, read-only view with retention rules. Security teams get a complete history of who approved what and when, without a separate system to maintain.

What we would do differently

We would define the event schema earlier and version it from day one. Changing events after customers depended on them taught us patience and, eventually, a careful migration process.