Three changes in October tighten how conditions match and how credentials are handled. A wildcard condition no longer acts as a regular expression by accident. A saved secret never appears in a read response. The alert event list API no longer runs queries without a time bound.
Wildcards match other characters literally
Filter conditions are used in channel dispatch policies, silence and inhibit rules, alert aggregation, routing rules, label enrichment, and alert processing. In a wildcard value, only two characters are special now:
*matches any run of characters, including none.?matches exactly one character. It used to match zero or one.
Every other character matches itself. ., +, (, ), [, ], |, ^, and $ are no longer regular expression syntax. For example, gpt-5.5* no longer matches gpt-5x5, and host[0-9]* only matches values that start with the text host[0-9]. To use a character class or a group, write a regular expression between slashes, such as /^host[0-9]+.*$/.
Stored wildcard values that were really regular expressions, for example ones using .*, +, [ ], or |, have been rewritten to the equivalent /^…$/ form, so they match the same alerts as before. Values whose only special characters are . or parentheses were left as they are and now match those characters literally. If you rely on one of them, check that it still matches what you expect.
Integration secrets read back as ******
Every read of an integration, in the console and through the API, shows a saved secret as ******. This covers webhook endpoints, header values, and custom payloads, HTTP pull URLs, headers, and bodies, the database pull password, the app secrets, tokens, and AES keys of Feishu/Lark, DingTalk, and WeCom, the Jira and ServiceNow passwords, and the ServiceDesk Plus credentials.
- When you save, a secret you leave as
******or omit keeps its stored value. - Changing where a secret is sent, such as an endpoint, a URL, a database host or port, or a ServiceNow instance, while keeping the stored secret is refused. Enter the secret again with the new destination.
Alert event list API needs a time range
POST /alert-event/list now requires start_time and end_time in Unix seconds, and the range can't exceed 31 days. A request without them used to query with no time bound. Out-of-range requests return the time range must not exceed 31 days.
Get started
Review wildcard values in your filter conditions, especially ones that contain . or parentheses, and update any API client that lists alert events without a time range.
Product docs: Filter conditions.