Detect the incident.
Diagnose the cause.
Enrich the ticket.
KernalHQ monitors and diagnoses incidents across AWS, Azure, and Google Cloud. It detects the failure, collects the supporting evidence — logs, execution history, and cloud-native signals — classifies the likely cause with a confidence score, and surfaces the diagnosis in your dashboard and in the GitHub or Jira ticket your team already works from.
No credit card required — free tier includes 1 service.
From alert to diagnosed incident
One asynchronous pipeline runs on every finding — off to the side of detection, so it never blocks it.
Detect
A finding opens when a monitored cloud workload crosses a health threshold — with a severity and tracked state.
Collect evidence
The platform's logs or execution history are queried over a bounded window, top error signatures and metric context are extracted, and secrets are redacted before anything is stored.
Diagnose
A rules-first engine classifies the most likely failure category with a confidence score — or returns an honest "inconclusive" when the evidence is thin.
Enrich
The diagnosis is surfaced in the KernalHQ dashboard and written into the finding's GitHub or Jira ticket, updated as evidence improves, and the ticket closes automatically on recovery.
More than monitoring. An actual diagnosis.
Most tools detect and notify, then stop. KernalHQ does the reading — turning each incident's own evidence into a failure category, confidence, and next steps, shown in your dashboard and attached to the ticket.
Evidence-backed diagnosis
A fixed, auditable failure taxonomy — timeouts, out-of-memory, throttling, auth denials, dependency and network failures, missing config or secrets, startup crashes, storage pressure, queue backlog — derived from the incident's own logs.
Honest confidence
Every diagnosis carries a confidence band and score. When the logs don't support a conclusion, KernalHQ marks it inconclusive instead of inventing a root cause.
See it where you work
The diagnosis shows up in your KernalHQ dashboard — a findings list and a dedicated detail view — and is written into the issue your team already opens: a structured section in GitHub, a panel in Jira, updated in place as the evidence sharpens.
Repeated-incident history
Fail, recover, fail again — each lifecycle gets its own immutable record and its own ticket. The new incident never overwrites the last one.
One model, three clouds
The same failure taxonomy and confidence model across runtimes, containers, data services, and workflows on AWS, Azure, and Google Cloud — read from each cloud's native logs, execution history, and diagnostics.
Redaction & guarded summaries
Secrets and PII are stripped from evidence before it's stored or written anywhere. An optional plain-language summary can sit above the diagnosis — validated, non-authoritative, and off by default.
Multi-cloud diagnosis across AWS, Azure, and Google Cloud
Monitoring spans 56 services across the three clouds. Evidence-backed diagnosis covers a broad, growing set — runtimes, containers, data services, and workflows — read from each cloud's native logs, execution history, and diagnostics. It's selective, not universal: where a service isn't diagnosed, KernalHQ still monitors and alerts.
Diagnoses Lambda, RDS, ECS, Step Functions, and Glue from CloudWatch Logs and Step Functions execution history (CloudFront is metric-only). Connected via a cross-account IAM role scoped to your tenant's external ID — no access keys stored.
Diagnoses Functions, App Service, Container Apps, AKS, Data Factory, SQL Database, and API Management from Application Insights and Log Analytics. Connected via a service principal (app registration) granted Reader access — the client secret is stored encrypted and never returned.
Diagnoses Cloud Run, Cloud Run functions, GKE, Cloud SQL, Compute Engine, and Workflows from Cloud Logging. Connected via a service account granted Viewer and Monitoring Viewer roles — the key is stored encrypted and never returned.
Monitoring health checks run through Amazon CloudWatch on AWS, Azure Monitor on Azure, and Cloud Monitoring on Google Cloud. Diagnosis reads each platform's native evidence — CloudWatch Logs, Cloud Logging, Application Insights, Azure Log Analytics, and Step Functions execution history. Where evidence isn't reachable, KernalHQ reports it honestly instead of guessing.
See the diagnosis where you work
The diagnosis surfaces in three places: your KernalHQ dashboard, the GitHub or Jira ticket your team already uses, and the alerts that page the right people. It stays current as evidence sharpens and closes on recovery.
Every finding carries its diagnosis inside KernalHQ itself — no ticket required. The category, confidence, representative error, and evidence are yours to review as the incident unfolds and after it's over.
Open a finding to see its failure category, confidence, a representative error, and suggested next steps — with the evidence provenance behind them. Diagnosis also appears inline in the cloud activity feed.
A size-capped, redacted evidence bundle is persisted per incident, so the diagnosis stays reviewable after the underlying logs age out.
The diagnosis lands where the work happens. KernalHQ writes a structured diagnosis into the ticket, rewrites it in place only when the evidence materially improves, and never opens a duplicate for the same incident. Each lifecycle keeps its own ticket and history.
Opened on detect via GitHub OAuth. A structured diagnosis section is written into the issue and updated in place as evidence sharpens; the issue closes automatically on resolve.
ADF ticket via Jira OAuth 2.0 (3LO). The diagnosis renders as a structured panel in the description, updated as evidence sharpens and transitioned through your workflow on resolution.
Notifications open the ticket and page the right people when findings open or resolve. Delivery is idempotent and queue-backed — duplicate evaluations never double-send.
Block Kit messages via incoming webhook, with rate-limit backoff. The webhook URL is stored and never returned in API responses.
Adaptive Cards (v1.2) delivered to any channel via webhook. SSRF-safe hostname validation on every outbound request.
Severity-stamped HTML via Amazon SES to validated org-member addresses. Recipients are configurable per monitored resource.
Pricing scales with what you monitor
Detection, diagnosis, dashboard surfacing, and GitHub/Jira enrichment are included on every tier for the services we diagnose. What scales is how many services you monitor.
Free
$0/mo
Try it on one service. No card required.
- 1 monitored service
- 1 seat (owner only)
- Email & Slack notifications
- Findings dashboard with diagnosis
Pro
$29/mo
Full workflow automation across your team.
- 10 monitored services
- Up to 5 team members
- Slack, Teams, and Email notifications
- GitHub Issues & Jira ticket automation
Enterprise
$99/mo
Scale-out coverage for large engineering orgs.
- 50 monitored services
- Up to 25 team members
- All Pro features
- Priority support
Common questions
Which workloads does KernalHQ diagnose?
A broad set across all three clouds. On AWS: Lambda, RDS, ECS, Step Functions, and Glue (CloudFront is metric-only). On Azure: Functions, App Service, Container Apps, AKS, Data Factory, SQL Database, and API Management. On Google Cloud: Cloud Run, Cloud Run functions, GKE, Cloud SQL, Compute Engine, and Workflows. Diagnosis reads each platform's native evidence — logs, execution history, and diagnostics. Coverage is selective rather than universal: where a service isn't diagnosed, KernalHQ still monitors and alerts. See Coverage.
Where do I see the diagnosis?
In three places. Inside the KernalHQ dashboard — the findings list, a dedicated finding detail view, and inline in the cloud activity feed — you see the failure category, confidence, a representative error, evidence, and suggested next steps. The same diagnosis is written into your GitHub issues and Jira tickets as a structured section, updated as evidence sharpens. And alerts to Slack, Teams, and email page the right people when findings open and resolve.
Does it open, enrich, and close tickets automatically?
Yes. KernalHQ opens a GitHub Issue or Jira ticket when a finding opens, writes and updates the structured diagnosis in place, and closes the issue or transitions the ticket through your workflow when the service recovers — without creating duplicates for the same incident. Each incident lifecycle keeps its own ticket and history record.
Does it use AI?
The diagnosis engine is deterministic and rules-based — a fixed, auditable failure taxonomy over the collected evidence. An optional plain-language summary can be model-generated, but it's schema-validated, cross-checked against the diagnosis so it can't introduce new facts, non-authoritative, and off by default. The structured diagnosis is always the source of truth.
What about secrets in our logs?
Evidence is redacted before it's stored or written to a ticket: cloud access keys, tokens, secrets, connection-string credentials, and emails are stripped out. When the logs don't support a conclusion, KernalHQ reports the finding as inconclusive rather than fabricating a cause.
How do the AWS, Azure, and Google Cloud connections work?
On AWS, you create an IAM role that trusts the KernalHQ account, scoped to a unique external ID assigned to your tenant — so only KernalHQ holding your exact external ID can assume it. On Azure, you register a service principal and grant it Reader access; only an encrypted reference to the client secret is stored, never returned. On Google Cloud, you create a service account with Viewer and Monitoring Viewer roles; only an encrypted reference to the key is stored, never returned. No long-lived access keys or passwords are stored, and any connection can be removed from your dashboard at any time.
Start triage with a diagnosis, not a log search.
Connect a cloud service and let KernalHQ detect, collect evidence, diagnose, and surface the cause in your dashboard and tickets — automatically.