Rank log level severity order
Log levels are easy to recognize but surprisingly easy to order incorrectly when configuration, filtering, or alerting code is assembled dynamically.
Run — free
This capability applies the conventional progression from trace through fatal, sorts a supplied list, and compares two named levels in the same request. It returns normalized lowercase names, the complete reference order, and an explicit relationship that is convenient for scripts, tests, dashboards, and documentation tools. Unknown names fail clearly instead of being guessed or silently placed at one end of the result.
Use one conventional severity scale
The capability uses the widely recognized ascending order trace, debug, info, warn, error, fatal. Trace represents the most detailed diagnostic events, while fatal represents failures severe enough to stop a process or make it unusable. Send the levels you actually encountered in the <code>levels</code> array. The result includes <code>sorted_levels</code> from least to most severe and <code>severity_order</code> as a complete reference. Repeated values are preserved because duplicates may represent real entries in a configuration, sample, or report. Sorting is stable for equal values. Names are trimmed and matched without regard to letter case, then returned in canonical lowercase form. The accepted vocabulary is deliberately narrow: an unfamiliar value such as notice, verbose, warning, critical, or emergency is rejected. Those names belong to other logging conventions and cannot be mapped to this six-level scale without making a policy decision on the caller's behalf. Explicit rejection makes configuration mistakes visible before they affect filtering or incident response.
Read the comparison result
Provide <code>first</code> and <code>second</code> to compare two levels alongside the sorting operation. The response normalizes both operands and reports a <code>relation</code> from the first level's perspective. A value of <code>more_severe</code> means the first operand appears later in the standard order; <code>less_severe</code> means it appears earlier; and <code>equal</code> means both operands resolve to the same level. The signed <code>rank_difference</code> adds precise distance: a positive number favors the first operand, a negative number favors the second, and zero represents equality. For unequal operands, <code>more_severe</code> names the winner directly, which saves clients from repeating the comparison. For equal operands that field is omitted rather than set to null. This shape works well in assertions and conditional automation. For example, comparing warn with error produces a negative difference and identifies error as more severe. Comparing ERROR with error produces equality after normalization, making case differences harmless without weakening validation of the actual vocabulary.
Apply ranking safely in developer workflows
Severity ranking is useful wherever text configuration must become an unambiguous decision. A log viewer can order selected filters before displaying them. A deployment checker can verify that a production threshold is at least warn. A documentation generator can present levels consistently even when its source file lists them out of order. Monitoring tests can compare the configured threshold with a required minimum and fail before a release reaches production. The function is deterministic and performs no network requests, so the same input always yields the same output in the browser and through the API. Keep in mind that this tool ranks names; it does not parse log lines, infer a level from message content, or translate between incompatible schemes such as syslog and custom application labels. If your system uses notice, critical, panic, off, or numeric levels, convert them according to your own documented policy before calling this capability. Rejecting unknown inputs is intentional protection against silently treating a misspelling as a real severity and accidentally hiding important events.
What you can do with it
Normalize a logging configuration
Sort a configuration's selected levels into conventional order and return consistent lowercase names.
Check an alert threshold
Compare a configured level with a required minimum and use the explicit relationship in a deployment test.
Build ordered documentation
Turn an arbitrary list of supported levels into a predictable progression for generated reference pages.
FAQ
What is the severity order?
From least to most severe, the order is trace, debug, info, warn, error, and fatal.
Are uppercase names accepted?
Yes. Names are trimmed, matched case-insensitively, and returned in canonical lowercase form.
What happens to duplicate levels?
Duplicates are preserved. Equal entries retain their original relative order.
Can I use warning or critical?
No. The accepted names are exactly trace, debug, info, warn, error, and fatal; other conventions require an explicit mapping by the caller.
How is rank_difference interpreted?
It is the first level's rank minus the second level's rank. Positive means the first is more severe, negative means the second is more severe, and zero means equal.
What does an API request cost?
Each API request costs $0.002. The same deterministic capability can also run free in the browser.
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/dev/log-level-severity-rank \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"levels":["error","debug","fatal","info"],"first":"warn","second":"error"}'const res = await fetch("https://api.kit.forhosting.com/dev/log-level-severity-rank", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"levels": [
"error",
"debug",
"fatal",
"info"
],
"first": "warn",
"second": "error"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/log-level-severity-rank",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"levels": [
"error",
"debug",
"fatal",
"info"
],
"first": "warn",
"second": "error"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/log-level-severity-rank", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"levels":["error","debug","fatal","info"],"first":"warn","second":"error"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"levels":["error","debug","fatal","info"],"first":"warn","second":"error"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/log-level-severity-rank", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"levels": [
"error",
"debug",
"fatal",
"info"
],
"first": "warn",
"second": "error"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.log_level_severity_rank",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_items | 1000 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |