Alert Bounds Out Of Order

URI: https://docs.ankatech.co/errors/alert-bounds-out-of-order
HTTP Status: 422 Unprocessable Entity

When you see this

A platform settings write was refused because, once applied, it would leave the CRITICAL bound of the sign-in refusal alerts below their WARNING bound. The two settings bound one count — refused sign-in steps per hour, for the whole deployment — so the CRITICAL bound must be at least the WARNING bound:

• ALERT_SIGNIN_FAILURES_WARNING_PER_HOUR — the bound above which the WARNING alert signin.failures.high holds (default 200);
• ALERT_SIGNIN_FAILURES_CRITICAL_PER_HOUR — the bound above which the CRITICAL alert signin.failures.critical holds (default 2000).

The write is judged against the value the other setting has in force, and refused before anything is stored, published or audited: the settings in force are exactly the ones you had before the request. Two writes of the pair are applied one after the other, so the second is judged against what the first stored.

Which writes can be refused

A value outside 20–1000000, or one that is not an integer, is refused earlier with 400 by the setting's own validator. Equal bounds are accepted.

Common Causes

• Lowering both bounds by writing the CRITICAL bound first, while the WARNING bound still holds its old, higher value.
• Raising both bounds by writing the WARNING bound first, while the CRITICAL bound still holds its old, lower value.
• Resetting one bound to its default while the other is set beyond that default.

Response Example

The CRITICAL bound written as 150 while the WARNING bound is 200:

{
  "type": "https://docs.ankatech.co/errors/alert-bounds-out-of-order",
  "title": "Alert Bounds Out Of Order",
  "status": 422,
  "detail": "ALERT_SIGNIN_FAILURES_CRITICAL_PER_HOUR must be at least ALERT_SIGNIN_FAILURES_WARNING_PER_HOUR; this write of ALERT_SIGNIN_FAILURES_CRITICAL_PER_HOUR would leave it below. Change the two settings in the order that keeps the pair valid.",
  "instance": "/api/v3/admin/platform/settings/ALERT_SIGNIN_FAILURES_CRITICAL_PER_HOUR",
  "timestamp": 1793096100,
  "extensions": {
    "requestId": "4c9e2a71-8b3d-4f06-a5e2-7d1b9c3f0e48",
    "field": "ALERT_SIGNIN_FAILURES_CRITICAL_PER_HOUR",
    "relatedField": "ALERT_SIGNIN_FAILURES_WARNING_PER_HOUR"
  }
}

The WARNING bound written as 2500 while the CRITICAL bound is 2000:

{
  "type": "https://docs.ankatech.co/errors/alert-bounds-out-of-order",
  "title": "Alert Bounds Out Of Order",
  "status": 422,
  "detail": "ALERT_SIGNIN_FAILURES_CRITICAL_PER_HOUR must be at least ALERT_SIGNIN_FAILURES_WARNING_PER_HOUR; this write of ALERT_SIGNIN_FAILURES_WARNING_PER_HOUR would leave it below. Change the two settings in the order that keeps the pair valid.",
  "instance": "/api/v3/admin/platform/settings/ALERT_SIGNIN_FAILURES_WARNING_PER_HOUR",
  "timestamp": 1793096100,
  "extensions": {
    "requestId": "9d2f6b14-3a5e-4c87-b0d1-6e8a2c4f7b93",
    "field": "ALERT_SIGNIN_FAILURES_WARNING_PER_HOUR",
    "relatedField": "ALERT_SIGNIN_FAILURES_CRITICAL_PER_HOUR"
  }
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.

The body carries two extension members beside extensions.requestId:

• extensions.field — the setting the refused request wrote or reset;
• extensions.relatedField — the other bound of the pair, the one it was judged against.

The detail names both settings and never echoes a value. Dispatch on type and read the extension members, never the detail.

The refusal cannot be acknowledged: acknowledgeAffectedTenants, which other settings refusals accept, has no effect on it. An out-of-order pair is not made valid by confirming it.

How to Resolve

1. Read the bound named by extensions.relatedField and decide the pair you want.
2. Write the two settings in the order that keeps the pair valid at every step:
   • to raise both bounds, write the CRITICAL bound first, then the WARNING bound;
   • to lower both bounds, write the WARNING bound first, then the CRITICAL bound.
3. To reset both to their defaults, reset the bound whose default keeps the pair valid first — for example, reset the WARNING bound before the CRITICAL one when the WARNING bound is set above 2000.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.