Analyze logs
A production incident dumps fifty thousand log lines on you at 3am, and buried in there are maybe a dozen that actually explain what broke. This endpoint reads raw log text and returns the errors, anomalies and patterns worth your attention, ranked and grouped, so triage starts with a short list instead of a scroll bar that never ends.
Run it online
Run this on our servers with your account. Free tools run in your browser; this one bills your KIT balance per the price above.
The needle-in-haystack problem
Application logs are written for completeness, not readability during an incident — a healthy request and one about to bring down checkout get logged at the same verbosity, interleaved across a hundred concurrent connections. On-call engineers know the ritual of grepping for 'ERROR' and still drowning in noise, because the real signal is often a pattern across lines, not a single line with that word in it. Log analysis exists to do that pattern-spotting automatically, at the speed an incident demands.
What you send and what you get back
POST raw log text — plain lines, JSON logs, or a common structured format — to /text/log-analyze, optionally with context like the service name or time window you care about. The task runs async: a task_id returns immediately, and the analysis lands at your signed webhook or a signed link valid for 24 hours, structured as grouped findings — a repeated error signature, an unusual spike, a sequence that precedes known failure modes — each with the log lines that support it, so you can jump straight to the evidence instead of re-deriving it.
How it separates signal from noise
It looks for repetition, sequence and deviation from the log's own normal patterns rather than matching a fixed list of known error strings, which is what lets it catch a new failure mode you've never seen before. That's the instinct an experienced SRE develops after enough postmortems — noticing a burst of timeouts on one service always precedes a cascading failure on another — encoded into something that reads a log file the same careful way every time, without the fatigue of doing it at 3am for the tenth time this quarter.
Fitting it into an incident workflow
Because it's async and priced per volume of lines, it works equally well triggered automatically by an alert (send the last hour of logs the moment error rate spikes) or pulled manually mid-incident to make sense of a dump someone just pasted into a channel. The webhook can feed straight into your incident-response tooling, turning a raw log analysis into the first comment on the ticket before a human finishes reading the alert.
What it won't tell you
It surfaces what's abnormal in the logs; it doesn't have access to your deploy history, infrastructure state or business context, so a finding like 'error rate for /checkout increased 40x at 14:02' is the starting point for your investigation, not the root-cause conclusion. That framing is intentional — the tool's job is to save you from reading fifty thousand lines yourself, not to replace the engineer who knows what changed at 14:00.
What you can do with it
Incident triage automation
Auto-analyze the log spike that triggers an alert so the on-call engineer opens a ticket with findings already summarized.
Post-mortem log review
Feed the full incident window's logs through analysis to build the timeline of what actually happened, not just what was noticed live.
CI/CD pipeline failure diagnosis
Analyze a failed build or deploy's logs automatically and attach the likely cause to the failed job before an engineer even opens it.
Noisy legacy system monitoring
Run recurring analysis over a chatty log stream that's too verbose for simple keyword alerting to be useful.
FAQ
What formats does the log analysis API accept?
Plain text log lines, JSON logs and other common structured formats are all supported; send the raw text as it's produced without reformatting it first.
How does it decide which log lines matter?
It looks for repetition, sequence and deviation from the log's normal patterns rather than a fixed keyword list, so it can catch failure modes it hasn't seen labeled before.
Is there a free tier for testing it on my logs?
There's no free tier — free tiers get abused and slow everyone down. Access runs on a prepaid ForHosting KIT balance: top up from $10.00 (it never expires) and each request is charged at its published price, so a call with no balance returns HTTP 402. No subscription, no tokens, no invented credits, and a failed task is never charged.
How is log analysis priced?
$0.003 per request plus $0.0135 per 1000 lines analyzed, so cost scales predictably with log volume rather than a flat per-file fee.
How do I get the analysis results?
The task runs asynchronously: a task_id comes back immediately, and results arrive via your signed webhook or a signed link valid for 24 hours.
Can I send very large log dumps in one request?
Yes, bulk volume is the normal case for incident logs, and pricing scales linearly per 1000 lines with no arbitrary size cap.
Does it tell me the root cause of an incident?
It surfaces the abnormal patterns and error signatures worth investigating, which is the starting point for root-cause analysis, not a substitute for engineering judgment about what changed.
Can this run automatically when an alert fires?
Yes, it's built to be called programmatically the moment an alert triggers, with the webhook delivering findings straight into your incident tooling.
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, and soon from our app, email and Telegram.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/text/log-analyze \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"…"}'const res = await fetch("https://api.kit.forhosting.com/text/log-analyze", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "…"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/text/log-analyze",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "…"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/text/log-analyze", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"…"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"…"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/text/log-analyze", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"text": "…"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "text.log_analyze",
"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_tokens | 20000 |
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. |
422 | task_failed | The task failed after 3 retries. You are never charged for it. |