How to maintain a healthy Swimlane System Performance
To maintain a healthy, high-performing Swimlane platform, it’s essential to follow best practices that reduce resource consumption, prevent bottlenecks, and keep playbooks running efficiently. These guidelines help ensure fast execution times, minimal system load, and stable uptime by optimizing playbook design, managing data intelligently, avoiding costly search operations, and preventing unnecessary queue usage. By adopting these tips, teams can keep their automation environment clean, resilient, and scalable—supporting smoother operations and a more reliable overall system.
Tip | Why do this? | System Benefits |
|---|---|---|
Disable integrations/playbooks when not in use or undergoing development work | When developing playbooks/applications misconfigurations/mistakes can be made and this can cause unnecessary executions causing playbooks to be delayed | Prevents excess system resource usage |
Optimise playbooks by splitting up integrations/playbooks into sub-playbooks | Optimises the run times of the playbooks allowing for fast execution times | Lowers memory usage while also making it easier to read and follow playbooks |
Keep record sizes small by keeping only the useful data in records and the number of references to other tickets low | This allows you to keep your fast record loading times and also keeps search queries fast | Keeps memory utilisation low and CPU resources under control |
Split up cron jobs and have them run at staggered times | Optimize the run times of the playbooks by avoiding scheduling conflicts allowing them to complete quicker without unnecessary queue times | Lowers memory usage, queue times and CPU usage |
Avoid using contains or complex searches when possible | Running a search with many conditions or using contains takes longer to match; avoiding these ensures faster results | Keeps memory utilization low |
Avoid using “Record Created” or “Record Updated” triggers when you also have “Create Record” or “Update Record” actions | Using both in a playbook risks causing an infinite loop that consumes job queues and unnecessary system resources | Keeps the system up and running without unnecessary resource usage |
Export a playbook before making heavy modifications | Allows you to quickly restore if issues occur and a fast resolution is needed | Enables quick restoration and keeps playbooks in a working state |
Set loops to run sequentially (default is parallel) | Sequential loops ensure actions run in the defined order; parallel loops can cause delays and queue overload | Keeps system resource utilization down as fewer parallel jobs run |
Regularly clean up playbooks | Test playbooks can be forgotten and take up space; names also become unavailable | Keeps storage space utilization low |
Utilize connectors already created in the marketplace | Developing custom connectors is time-consuming and untested ones may negatively impact system resources | Marketplace connectors are optimized and prevent unnecessary resource consumption |
Reusable playbooks | Designing for reuse allows playbooks to be quickly applied to other use cases when configurable | Keeps storage utilization low and can provide fast run times |
Develop and test on a Test/Staging tenant before Production | Mistakes in Production can halt the system or cause undesired outcomes | Ensures system uptime |
Playbook configuration: Timeouts & Limits | Consider timeout settings, ingest amounts, and data sizing; bulk ingesting alerts can cause delays or timeouts | Low resource utilization for playbooks |
Keep bulk edits small | Bulk edits require searching the database for many records; large edits cause heavy resource overhead | Reduces system resource consumption |