Pipefy had 62 outages in the last 2 years totaling 29h 57m of downtime — averaging 2.5 incidents per month.
There were 62 Pipefy outages since September 22, 2025 totaling 29h 57m of downtime. Each is summarised below — incident details, duration, and resolution information.
We are currently investigating this issue.
This incident has been resolved.
The incident was resolved
We are currently investigating this issue.
We are monitoring the incident.
The incident was resolved
We are currently investigating this issue.
This incident has been resolved.
This incident has been resolved.
The issue has been resolved and we are now monitoring it.
The incident was resolved
We've spotted that something has gone wrong. We're currently investigating the issue, and will provide an update soon.
A fix was applied, and the incident was resolved.
The issue has been identified and a fix is being implemented.
This incident has been resolved.
We are currently investigating this issue.
This incident has been resolved.
**Root Cause** The issue was caused by an automation process that affected the system's performance. During this time, the speed of processing tasks was slower than usual, impacting the overall efficiency. **Resolution** The problematic automation was removed, which restored the system's performance back to its normal state, ensuring that operations could continue smoothly.
We are currently investigating this issue
The application is online, but users may still experience degraded performance or intermittent issues. Our engineering team is closely monitoring system health as we work towards full restoration
This incident has been resolved.
**Root Cause** The issue was traced back to a firmware update in a database instance, which led to a failure in the system's ability to switch over to a backup. This caused the main application to go down. **Resolution** The problem was resolved by starting the database on a new healthy instance, restoring the system's functionality. **Action Plan** - To prevent future occurrences, a manual switch-over will be performed before any instance restarts. - Additionally, a maintenance is scheduled for the system update to address the identified bug.
Dear customers, We are currently aware of an issue affecting a subset of our customers where iPaaS flow executions are experiencing longer-than-expected processing times. We want to be transparent: Your flows are running. The behavior some customers are noticing is a delay in the time it takes for each process to be picked up and started — once a run begins, it proceeds normally. Our engineering teams are actively investigating the root cause and working to restore standard processing times as quickly as possible. We do not have an ETA to share at this moment, but we are committed to keeping you informed as the situation evolves. If you have been impacted, no action is required on your end. We will provide updates in our Statuspage as they become available. We apologize for any inconvenience this may cause and appreciate your patience.
This incident was resolved after a fix being implemented
We are currently investigating this issue.
We are continuing to investigate this issue.
This incident has been resolved.
The issue has been identified and a fix is being implemented.
**Root Cause** The application experienced performance issues due to a spike in executing flows that affected the app's performance. During the investigation, an issue was identified, requiring a fix to resolve the problem permanently. **Resolution** A fix to address the issue was implemented in the application, ensuring the application's performance returned to normal. **Action Plan** The team will monitor new metrics in the scenario, to avoid the future impact
Some new performance patches was applied during the monitoring period and we consider the incident resolved now. The app performance is back to an expected level and all operations are running normally. We apologize for the incident and the entire team evolved both technically and operationally to prevent this in the future.
We are currently handling an issue with our cache system greatly decreasing app performance to load Pipes and Cards. It can take several seconds to fully open a Pipe and even errors can occur preventing the content to be loaded. Our team have already identified the root cause of the problem and are working in the solution. We expect to have the problem solved soon. We will update this page once the incident is closed.
The incident is now fixed and we are back to operational status. Several patches was deployed in order to get the minimum expected App performance. We still could not get back to ideal performance but it should be more than enough to handle Pipefy's normal usage. We are still monitoring the servers and applying very specific changes to reach the ideal performance point.
A quick fix for the incident is online and the average App performance is sightly better. You must still notice some delay but most Pipes and Cards should load now. The team is still working in a final solution
This incident has been resolved.
The team is investigating an unexpected heavy load on our servers, which is affecting our database and app performance. We are working with our provider to identify and solve this issue. We are sorry for the inconvenience and we are working on a fix.
The team identified and solved the performance problems, and Pipefy should be usable again. However, some reports might display data which is not entirely up-to-date. We are solving the issue and will continue to monitor the other aspects of the app.
All data is restored and reindexed again in our Elastic Search. We are investigating whats happen in a post mortem meeting and find a better solution to prevent that it's happens again.
The team is currently working on a major incident involving the indexing server. This greatly affect the Reports page among multiple others search related features. We already initiate the recovery process and all systems should be back operational soon
The team is investigating a major outage incident affecting all of our servers. We are sorry for the inconvenience and will fix as soon as possible
This incident has been resolved. Today at 1:58 PM (UTC) our monitoring service identified a failure to communicate with the Redis database service responsible for background jobs. At 2:00 PM (UTC) our team decided to put our disaster recovery in action, creating a new database that was finished successfully at 14:10 (UTC). Our automated test was run to check the overall status of the system. We've also put it online again for all users at 14:12 (UTC).
We are having a problem communicating with one of our databases, we are investigating
The tests were successful and the system is working again. We are working to improving this script so that this problem does not happen again.
The problem was identified, a maintenance service that runs between Saturday and Sunday to improve the database's health was not successful to get connection the it's forcing to get one. Now we're running the complete infrastructure tests to make sure that when we vote everything is settled and no problem. Our service will return in 15 minutes.
The team already identified a major incident affecting all of our services. Team is already applying the fix but unfortunately we need to take the service briefly offline.
The issue has been identified and a fix is being implemented.
Fix has been applied and we are monitoring the service
This incident has been resolved.
During a Redis migration our team identified a failure in HA, provided by our PaaS, which didn't run as expected. That failure occurred between 0:14 AM and 0:17 AM (UTC) and was promptly handled by our Ops Team.
We identify the problem, it happened because the gem [sequenced](https://github.com/derrickreimer/sequenced) that we use in our Ruby project locked the phase table, after that this process died and table stay locked. We kill the process and restart the application that returns to respond as expected. Now we are removing that gem and move this logic to our database that can do this job in the same process and prevent this error.
All systems are operational now. We will keep monitoring our Application and Databases. More information will be provided as soon as possible.
Our team are investigating a high error and timeout rate which is causing instability in our service. More details will be provided soon.
We faced some latency in Pipefy few minutes ago. We have checked and system is ok now! The official report from Heroku: Engineers have rolled back a recent platform change and are beginning to see dynos booting normally. We're continuing to monitor platform health. Related incident: https://status.heroku.com/incidents/1539
We're monitoring our infrastructure for approximately 1 hour and everything looks ok. Heroku also closed their incident: https://status.heroku.com/incidents/1539
Our queues are up and running at normal throughput. We will keep monitoring it.
We are currently investigating a delay in our background queues which affects automations and notifications.
The cause of indexing delay was a high CPU usage in the cluster. We had to stop the processing of our Elasticsearch jobs in order to restore the cluster heatlh. The cluster is backing to normal status and we are gradually restarting our Elasticsearch queues. The root cause of this CPU spike is being investigated with our cloud provider.
We are currently investigating a indexing delay in our Elasticsearch cluster.
Almost all our background queues and indexing jobs finished. We are still working on a few indexing jobs and still monitoring the workers and Elasticsearch cluster.
This incident has been resolved. All our queues and Elasticsearch cluster are up and running normally. We will keep investigating the root cause and will work in order to improve our infrastructure.
We have identified that a recent internal infrastructure update caused unexpected rate-limiting on our iPaaS platform, resulting in temporary delays or 429 errors in workflows for the custom integrations. Our Infrastructure team has identified the root cause and successfully applied a fix to restore normal traffic. We're closely monitoring the environment to ensure stability. Normal service operation is expected across all affected organizations.
This incident has been resolved. Additional information will be provided shortly in our postmortem report.
**Root Cause** Recently, efforts were made to separate the infrastructure for better handling of increased demand. This led to the failure of previously set exception rules. An update was applied to a specific host or domain without verifying its use in the integration, causing issues. **Resolution** The issue was resolved by modifying the configuration rules on Ipass app. **Action Plan** - An anomaly alert will be created for the Ipass to avoid this scenario happend again in the future
On March 30th, the platform experienced a degradation that impacted filter and search applications. This incident was opened retroactively to provide visibility to customers. The problem is no longer occurring at the moment. Thank you for your understanding.
This incident has been resolved.
We are currently investigating this issue.
A fix has been implemented and we are monitoring the results.
We are continuing to monitor for any further issues.
This incident has been resolved.
**Root Cause** The issue was caused by a failure in the integration feature, which led to an overload in the system. An unoptimized job created thousands of subflows, quickly filling up memory and affecting system availability. The misuse of the integration was identified as the root cause, prompting the disabling of the problematic flow as an initial step to mitigate the issue. **Resolution** To resolve the issue, the team deactivated the problematic flow and partially cleared the queues. This initial solution aimed to prevent new calls and address the items stuck in the queue. **Action Plan** **We will continue to monitor the system closely to ensure stability and prevent future issues. Our focus remains on continuously improving the customer experience by optimizing our processes and enhancing communication between teams.**
We are currently investigating this issue.
We are continuing to investigate this issue.
A fix has been implemented and we are monitoring the results.
This incident has been resolved.