Unfortunately yes, we had an issue and are in the middle of fixing it, should be reenabled tomorrow. If you had any issues with this being rolled back, please file a support ticket and we can help fix it.

@hpsin Thanks for the quick reply! No issues, but we were about to use this wildcard feature when it suddenly disappeared 👍

Quick question: The recommendation is to not use wildcards. But let's say we own somedomain.com and we have many customer specific deployments i.e. <somecustomer[1..100]>.ourdomain.com. We use the OAuth flow. Without wildcards, we need to create a separate callback service that redirects users to correct places. So the question is, against what is recommended, are there any negatives of using wildcards in this case as opposed to having a separate callback service?

It's now re-enabled. Sorry about that!

And yes this is what the wildcard is intended for, precisely.
The downside of this is that it's not a scoped wildcard match - it'll match Foo.somecustomer1.ourcompany.com/a/long/path as well.

The downside here is risk - you have to do more diligence about your app architecture to make sure an expansion of the subdomains and path can't become something risky.