← Back to Signal
Bug Escalation TicketDraft

Bug Escalation Ticket: Workflow execution is too slow, especially for large or complex workflows

Last updated 2026-05-11

Draft — review content and approve to promote this artifact.

Problem Statement

Workflow execution performance is critically degraded across multiple dimensions, including trigger latency, batch processing, UI responsiveness, and dashboard load times. Users across Team, Mid-market, and Enterprise plan types report execution delays of 30 seconds to several minutes, browser tab crashes during multi-step workflows, and complete UI lock-ups during batch runs. The issue has worsened recently, with at least one Team-tier user noting significant degradation in the last two weeks, suggesting a possible regression.

Evidence Summary

18 feedback items across Team, Mid-market, and Enterprise tiers, 9 rated CRITICAL, 7 HIGH, 2 MEDIUM, document four distinct performance failure modes: (1) Slow execution: Team users report simple automations taking 30+ seconds; Mid-market and Enterprise users report larger workflows taking several minutes (CRITICAL, Mid-market x2; HIGH, Team x2). (2) Trigger latency: Mid-market and Enterprise users report up to 5-minute delays between trigger event and workflow firing (HIGH, Mid-market; CRITICAL, Enterprise). (3) UI lock-up and crashes: Team and Mid-market users report batch runs locking the UI entirely (CRITICAL, Team; MEDIUM, Mid-market), and one CRITICAL Mid-market report of browser tab crashes during multi-step workflows. (4) Dashboard and app slowness: Team and Mid-market users with 50 active workflows report 10-second dashboard load times (HIGH, Team; HIGH, Mid-market); Enterprise users report noticeable slowness with 5+ active workflows and further degradation during peak hours (CRITICAL, Enterprise). The Google Sheets sync benchmark, 8 minutes for 500 rows, provides a concrete, measurable data point illustrating the scale of degradation (HIGH, Mid-market).

Priority Rationale

The signal scores 88/100 at high confidence, reflecting the breadth and severity of impact. CRITICAL-severity reports span all three plan tiers, with Enterprise and Mid-market users, who represent the highest-value accounts and typically run the highest workflow volumes, disproportionately affected. Multiple CRITICAL Enterprise reports of peak-hour slowdowns and 5-minute trigger latency suggest systemic infrastructure stress rather than isolated edge cases. The reported regression over the last two weeks (MEDIUM, Team) raises the urgency of investigation to identify whether a recent deployment or infrastructure change is a contributing factor. Continued degradation at this severity risks churn among high-value accounts and undermines core product reliability.

Acceptance Criteria

  • Simple automations (≤5 steps, no external integrations) execute end-to-end in under 5 seconds under normal load conditions, resolving the reported 30+ second execution times for Team users.
  • Workflow trigger latency from trigger event to execution start does not exceed 30 seconds under normal and peak load conditions, resolving the reported up to 5-minute delays seen by Mid-market and Enterprise users.
  • Batch operations including Google Sheets sync complete at a rate sufficient to process 500 rows in under 60 seconds, resolving the reported 8-minute sync time.
  • The UI remains fully responsive and interactive during batch workflow execution, no lock-ups or blocking states, resolving CRITICAL Team and MEDIUM Mid-market reports of complete UI freezes.
  • The dashboard loads in under 2 seconds for accounts with up to 50 active workflows, resolving the reported 10-second load times for Team and Mid-market users at that volume.

Steps to Reproduce

  1. Log in to a FlowPilot account with 10 or more existing active workflows.
  2. Navigate to the dashboard and record the load time to confirm whether it exceeds the reported 10-second threshold.
  3. Open or create a workflow with more than 10 sequential steps.
  4. Add a batch operation step, such as a Google Sheets sync targeting a sheet with 500 or more rows.
  5. Trigger the workflow manually and record the time elapsed from trigger event to execution start (trigger latency) and the total end-to-end execution time.
  6. While the batch operation is processing, attempt to interact with the UI (e.g., navigate to another workflow or open settings) and observe whether the UI is locked or unresponsive.
  7. Repeat steps 3–6 with 50 or more concurrent active workflows to reproduce peak-load conditions reported by Enterprise users.

Expected Behavior

Workflows should execute promptly after a trigger event (within seconds), the UI should remain fully interactive during execution and batch processing, dashboard load times should be fast regardless of the number of active workflows, and batch data operations such as Google Sheets syncs should complete within a reasonable time proportional to data volume.

Actual Behavior

Simple automations take 30+ seconds to execute; larger multi-step workflows take several minutes. Trigger latency reaches up to 5 minutes between the trigger event and workflow start. Batch runs such as Google Sheets syncs take up to 8 minutes for 500 rows. The UI locks up entirely during batch processing, preventing any interaction. Multi-step workflows occasionally crash the browser tab. The dashboard takes up to 10 seconds to load with 50 active workflows. The app slows down significantly during peak hours, and overall performance has degraded noticeably compared to two weeks prior.

Open Questions

  1. Is the performance degradation tied to a specific recent deployment or infrastructure change, given the Team-tier report of significant worsening in the last two weeks? What do server-side metrics and deployment logs show for that period?
  2. Are the UI lock-ups and browser tab crashes caused by blocking synchronous operations on the main thread in the frontend, a backend response timeout, or both, and do they share a root cause with the execution latency issues?
  3. Is peak-hour degradation (reported by Enterprise users) caused by shared infrastructure resource contention, and if so, does the fix require capacity scaling, request queuing improvements, or execution isolation per account?