Are you trying to use some unsupported Regex functionality? That's usually what happens to me when I try to leverage something IDR doesn't support.
From testing/docs, I believe that we cannot use unnamed capture groups and positive/negative lookahead/behinds. It seems to be some type of limitation with the Regex searching offered inside of IDR.
If you aren't using something like that, I do also have this issue sometimes with valid patterns. I run into it especially often when creating Custom Parsing rules, but also see it when running queries in Log Search.
Oddly enough sometimes I have luck getting it to run when I go back and set a filter on the preceding page during parsing rule creation.
I can set the regex rule, get it to freeze, go back and set a filter, go back to the regex and it will work. Doesn't seem to be reliable but worth trying.
If none of those work, often times I'll resort to making any parsing rule that does work, so that you can get the "source_data" key. From there, I usually have to hack together a combo of regex patterns and then ICONTAINS-ALL or ICONTAINS-ANY against the "source_data" key with whatever other patterns i want to make sure exist in the source data.
We recommend limiting your rules to about 8 keys for any given rule, and then saving and creating a new rule to pick up where you left off. The limit here comes down to your browser for the most part, it fails to compute the regex which is why we recommend fewer keys.
If this is one key with a very complex regex it may also fail