{{ summaryHeading }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }} {{ badge.value }}
Keep command scope and capture window consistent when comparing runs.
{{ sourceMeta }}
{{ fileStatus || 'Drop one TXT, LOG, JSON, YAML, or YML file onto the editor.' }}
The result records both the requested and resolved format; a pinned mode bypasses detection.
The label appears in summaries and handoffs so the capture keeps its incident context.
Start with the incident reasons your team escalates, such as BackOff, FailedScheduling, Unhealthy, or FailedMount.
The default shows the first 50 normalized rows without changing aggregate analysis.
rows
Use smaller buckets for incident bursts and larger buckets for longer timestamped captures.
min
Order / timeNamespaceTypeReasonObjectCountReporterMessageCopy
{{ row.when }}{{ row.namespace }}{{ row.type }}{{ row.reason }}{{ row.object }}{{ row.count }}{{ row.reporter }}{{ row.message }}
ReasonType mixRowsOccurrencesWarning shareTop objectLatest messageCopy
{{ row.reason }}{{ row.type_mix }}{{ row.rows }}{{ row.occurrences }}{{ row.warning_share }}{{ row.top_object }}{{ row.latest_message }}
ObjectNamespaceKindOccurrencesWarningsReasonsNext checkCopy
{{ row.object }}{{ row.namespace }}{{ row.kind }}{{ row.occurrences }}{{ row.warnings }}{{ row.reasons }}{{ row.next_check }}
FindingSeverityEvidenceSuggested next checkCopy
{{ row.finding }}{{ row.severity }}{{ row.evidence }}{{ row.next_check }}
{{ chartError }}
Kubernetes Resource Requests Checker Check Kubernetes manifests for missing resource requests and invalid limits, with QoS clues and scheduler-footprint evidence before rollout.
Kubernetes Pod Security Context Checker Check Kubernetes workload YAML for inherited security contexts, Pod Security gaps, weighted findings, and a reviewable hardening patch.
Kubernetes Cluster Capacity Calculator Estimate a rollout-safe Kubernetes replica ceiling from allocatable resources and pod requests, then test node loss and disruption limits.
Kubernetes Deployment Generator Build Kubernetes Deployment YAML with optional Service and policy resources, plus checks for rollout, probes, resources, and security choices.

Kubernetes Events are brief reports about work happening around cluster objects. A scheduler can report why a Pod remains Pending, a kubelet can report a failed mount or probe, and a controller can record progress during a rollout. These messages often point toward the next check before application logs are available.

An Event is not a durable incident record. It describes what one producer observed at a moment in time, and older Events may expire or remain visible after the object recovers. The Normal and Warning types help separate routine progress from conditions worth checking, but Warning is not a universal severity score and does not establish root cause.

Reason
A short category such as FailedScheduling, BackOff, Unhealthy, or FailedMount.
Message
The producer's human-readable detail, often naming a constraint, object, or failed operation.
Regarding object
The Pod, node, controller, volume, or other resource associated with the report.
Series count
The number of represented occurrences when repeated observations are folded into one Event row.

Rows and occurrences must stay separate. A line ending in (x4 over 2m10s) represents four occurrences, and Event JSON can carry the same idea in a series count. Treating it as one would understate a recurring problem. Repeat-aware totals preserve that weight while keeping the source row available for inspection.

Time can be exact or relative. Complete timestamps can be grouped into fixed UTC intervals to compare bursts with a rollout or node incident. An age such as 5m says how old a report was at collection time, but without that collection timestamp it cannot be placed on an absolute timeline. Ordered sequence is safer for captures dominated by relative ages.

Collection scope changes every ratio and ranking. A cluster-wide list, one namespace, and one object describe different populations. Keep the command scope and capture window stable when comparing warning share or reason concentration, and always check the current object state, logs, conditions, and controller status before making a change.

How to Use This Tool:

Use one recent capture with a known scope, then trace its strongest warning cluster back to live workload evidence.

  1. Collect Kubernetes Event evidence. Paste a kubectl events table, a describe Events section, timestamped Event text, or an Event JSON array or list. Input may contain up to 6 MiB.
  2. Choose Source format. Automatic mode prefers JSON when the entire source parses as Event JSON and otherwise uses text. Pin the mode when that resolution is wrong.
  3. Set Cluster slice label and Warning reason focus. The label records context but does not filter. Focus reasons use case-insensitive exact matching against Warning reasons.
  4. Check row count, occurrence count, resolved format, and timeline mode. If no Events parse, correct the format or convert structured YAML to Event JSON.
    Visible event rows changes only the ledger. Absolute-time bucket affects only captures with enough parseable timestamps.
  5. Start with Warning Triage. Follow its leading reason and object into current Pod or workload status, recent logs, controller output, and node conditions.

Interpreting Results:

Use occurrence-weighted counts for concentration and row count for source coverage. A single repeated Event may dominate warning pressure while still providing only one message and one object reference.

  • Reason Pressure orders reasons by Warning occurrences, all occurrences, then name. The latest message is the last parsed row for that reason, not necessarily the newest in time.
  • Object Hot Spots combines namespace and object, then ranks by Warning occurrences and total occurrences.
  • Absolute time supports interval comparison. Input order preserves sequence only; spacing must not be read as elapsed time.
  • No Warning events parsed describes the accepted capture. It does not rule out expired Events, missing scope, application failure, or unsupported text.

Triage labels are local rules, not Kubernetes severities. Confirm the newest relevant Event against the object's present conditions before treating an older warning as active.

Technical Details:

Event analysis normalizes text and JSON into one record shape, expands each row by its represented occurrence count for aggregation, and groups that evidence by reason, object, and time. Suggested checks are deterministic routing rules, not diagnoses returned by Kubernetes.

Transformation Core

StageRuleOutput
CleanRemove terminal escape sequences, normalize line endings, trim trailing spaces, and preserve non-empty row order.Normalized capture
Resolve formatUse JSON for an array or list with Event items; otherwise use the supported text path in automatic mode.Requested and resolved format
Map fieldsRead current and legacy JSON fields or common table, timestamped, and describe text shapes.Time, namespace, type, reason, object, count, reporter, and message
Count occurrencesPrefer series, legacy, or explicit count; recognize text suffixes such as (x3 over 1m); otherwise use 1.Row count and repeat-weighted occurrence count
GroupAdd occurrences by reason and by namespace plus object, preserving Warning and Normal totals.Reason and object rankings
Place eventsUse fixed UTC intervals when timestamp coverage passes; otherwise retain normalized input order.Event volume sequence

Event JSON recognizes fields such as regarding, eventTime, series.count, note, and reportingController together with legacy equivalents. Unknown text types become Warning only when the reason or message contains warning-like terms; other accepted rows become Normal.

Formula Core

Warning share uses represented occurrences rather than physical source rows.

S=OWOT×100%

OW is the sum of counts on Warning records, and OT is the sum across all accepted records. Evidence tables display percentages to one decimal place; occurrence totals remain integers.

When absolute placement is available, a timestamp is floored to the beginning of its selected interval.

tb=⌊tB⌋B

t and interval start tb are UTC milliseconds. B is the selected number of minutes multiplied by 60,000. Absolute-time mode requires at least two timestamped rows and timestamp coverage greater than or equal to half of all parsed rows. Equality at one half qualifies. Timestamps without an explicit zone are interpreted as UTC; relative ages remain relative.

Rule Core

FindingTriggerLabel
Focused Warning reason presentFocused Warning occurrences > 0 after exact case-insensitive matchingHigh
Warning pressure in captureWarning occurrences > 0 and share ≥ 40%High
Warning pressure in captureWarning occurrences > 0 and share < 40%Medium
No Warning events parsedWarning occurrences = 0Low
Repeated reason clusterLeading reason has more than 1 occurrenceMedium with any Warning occurrence; Info otherwise
Object hot spot with warningsLeading object has at least 1 Warning occurrenceHigh

The complete accepted capture supplies these rules even when the visible ledger is limited to 10 through 300 rows.

Lookup Core

A leading reason selects the first matching family below. This ordering matters because some terms can match more than one family.

OrderReason familySuggested evidence
1Failed scheduling, not scheduled, or preemptionNode capacity, taints, affinity, quotas, and scheduler messages
2Unhealthy or probeLiveness and readiness settings, endpoint health, and Pod-local reachability
3Mount, volume, or attachPVC/PV binding, CSI health, Secret or ConfigMap names, and attach errors
4Image pullImage name, registry reachability, imagePullSecret, and node pull errors
5Killing, eviction, or remaining preemption matchesTermination reason, node pressure, disruption budget, and eviction evidence
6Backoff, crash loop, or failureObject description, recent logs, restart count, and Event cadence
7No family matchAdjacent Events and current workload status

Reason groups sort by Warning occurrences, all occurrences, and reason name. Object groups sort by Warning occurrences, all occurrences, namespace, and object name. The selected interval accepts 1 to 240 whole minutes, and focus-reason text accepts up to 500 characters.

Limitations:

The analysis does not connect to a cluster, recover expired Events, or determine incident cause. Processing and exports remain in the browser, but captures can contain sensitive namespaces, object names, images, storage references, and operational messages.

  • Event retention, message wording, timing, and aggregation vary by producer and cluster configuration.
  • Unusual text layouts may be skipped or classified from warning-like words when structured fields are absent.
  • The file chooser accepts YAML extensions, but structured YAML is not mapped as Event JSON. Convert it or use readable command output.
  • The cluster slice label adds context only and never filters the source.
  • Relative ages cannot establish UTC spacing unless the collection time is preserved separately.

Worked Examples:

One repeated warning beside one progress row

A Normal Scheduled row counts once. A Warning BackOff row marked (x3 over 1m) counts three times. The two-row capture represents four occurrences, three of them Warning, so warning share is 75% and meets the High rule. Relative ages keep the sequence in input order.

Timestamp coverage at the exact boundary

In a four-row capture, two valid timestamps meet the one-half coverage rule. With 5-minute intervals, events at 10:01:20Z and 10:04:50Z both enter the 10:00:00Z interval. Untimestamped rows remain separate ordered entries, so the chart combines absolute intervals with preserved source evidence rather than inventing times.

References: