Every CPQ expert knows the feeling: You click "Run," and then… nothing. The spinner spins. The seconds stretch. Then finally — timeout.
Timeouts in a constraint-based configurator aren't just frustrating — they're telling you something. And after years of working with CPQ systems, I’ve come to see timeouts not as failures, but as clues.
In this post, I’ll walk you through a battle-tested approach to identifying and resolving these timeouts — especially when caused by custom search strategies or default settings that silently steer your model into a combinatorial nightmare.
A timeout typically means the configurator is backtracking. That is, it’s trying multiple combinations, undoing decisions, and trying again — sometimes millions of times — all in search of a valid solution.
Why does this happen?
Because search strategies — whether default or custom — guide the order in which decisions are made. If the strategy isn’t aligned with the problem structure, things can get out of hand quickly.
Over the years, I’ve seen countless models fail under custom search strategies that tried to be clever.
First step? Switch back to the default search strategy.
If the timeout disappears, you've learned something valuable:
Your custom search strategy is the culprit.
Custom strategies are powerful — but they can just as easily mislead the solver if features are prioritized in the wrong order.
Next, look for default values — especially those that are fixed early in the configuration. While helpful in guiding users, they can constrain the solver and cause it to backtrack more.
Even a single default set too early can force the solver down a path it can’t back out of.
Don’t test your changes manually every time — automate a test case that consistently triggers the timeout.
This lets you:
If your custom strategy is the root cause:
Once the timeout disappears, you’ve likely found your culprit.
A useful trick: move problematic decisions to the end of the strategy so they’re applied late — when the rest of the structure is more stable.
A fix is only a fix if it doesn't break something else.
A timeout isn’t a bug — it’s a sign that your model is struggling to make sense of the instructions it’s been given.
In my experience, 80% of timeout issues come down to poor search strategies or misused defaults. The good news? These are almost always within your control to fix.
So the next time your configurator stalls, take a deep breath. You’ve got a method, and you’ve got the experience.
And if all else fails — remember: sometimes, the model is trying to tell you something important.
If you're working with Tacton or any other constraint-based CPQ and want more deep dives like this, follow cpq.se/the-cpq-blog.
If you want to set up some coahing sessions together with one of our experts - set a up call with Magnus (link) and we'll make it happen.