Incident types

Every incident InsightX shows is one of the 14 kinds below. The title is the name you see at the top of the incident and in the incident list.

Crashes and failed health checks

For these, InsightX reads the evidence from your app, investigates, and writes the explanation. The incident shows a confidence figure and a What InsightX checked list.

Out of memory

Title: Out of Memory
When it appears: The operating system stopped your app because it used more memory than its plan allows. Your app exits with code 137.
What to do: Look for what is holding memory, such as large caches, files read fully into memory, or too many worker processes. If the app genuinely needs more memory, move the resource to a plan with more memory.

A crash that recovered

Title: Depends on the cause InsightX finds. See Titles for crashes.
When it appears: Your app crashed and Kuberns restarted it straight away, so it is running again. The incident shows ✓ Recovered automatically.
What to do: Read Why it happened. The cause is still in your app even though it recovered.

A crash that stayed down

Title: Depends on the cause InsightX finds. See Titles for crashes.
When it appears: Your app exited with an error and was still not running about 15 seconds later.
What to do: Follow What to do next. The app does not come back on its own until the cause is fixed.

A failing health check

Title: Application Error
When it appears: Your app is running, but the health check on its container keeps failing, so Kuberns treats it as unhealthy.
What to do: Check that your app answers its health check, and look at what the logs print around the time of the incident.

Titles for crashes

When your app crashes, the title names the cause InsightX identified.

Title	Meaning
Out of Memory	The app used more memory than it is allowed.
Database Unreachable	The app could not connect to its database or Redis.
Application Error	An error in your code, such as an unhandled exception or a failed import.
Port Conflict	The port the app needs is already in use.
Low Disk Space	The server ran out of disk space.
Missing Environment Variable	A required environment variable or setting is not set.
Segmentation Fault	The process crashed from invalid memory access.
Image Unavailable	The container image could not be found or pulled.
Startup Crash Loop	The app crashes as soon as it starts, again and again.
Service Crashed	The service restarted and no clearer cause was found.

Conditions Kuberns measures

For these, Kuberns measured the problem itself, so the cause is known and the explanation is fixed. The incident shows the measurement as evidence, and no confidence figure.

SSL certificate expiring

Title: SSL Certificate Expiring
When it appears: The certificate for your domain expires in 7 days or less. Certificates are checked every hour.
What to do: Nothing is broken yet. If the certificate is not renewed before it expires, visitors will see a security warning.

SSL certificate expired

Title: SSL Certificate Expiring
When it appears: The certificate for your domain has passed its end date.
What to do: Visitors see a security warning and some clients refuse to connect. Kuberns has been alerted.

Disk getting full

Title: Low Disk Space
When it appears: Disk usage on your server reached 90%. The disk is checked every hour.
What to do: Free up space. Disk usage does not go back down on its own, and a full disk stops your app from writing logs, uploads, and temporary files.

Disk almost full

Title: Low Disk Space
When it appears: Disk usage reached 95%.
What to do: Act now. Your app may already be failing to write files and can crash at any moment.

High CPU

Title: High CPU Usage
When it appears: Your app used 90% or more of the server's CPU in several checks in a row. This is sustained load, not a short spike.
What to do: Requests can be slow or time out while the CPU is saturated. Look for heavy work in your app, or move to a plan with more CPU.

High memory

Title: High Memory Usage
When it appears: Your app used 85% or more of its memory in several checks in a row.
What to do: Nothing has failed yet. If memory runs out, the app is killed and restarted.

Critical memory

Title: High Memory Usage
When it appears: Your app used 95% or more of its memory in several checks in a row.
What to do: Your app is very close to running out of memory. Reduce what it keeps in memory, or move to a plan with more memory.

A server out of memory

Title: High Memory Usage
When it appears: The server itself has run out of memory and has started using its disk as extra memory, which is far slower.
What to do: Your app slows down and can stop responding even though nothing has crashed. Move to a plan with more memory, or reduce what your app keeps in memory.

An app restarted to protect its server

Title: High Memory Usage
When it appears: Free memory on the server dropped below the safety level, so Kuberns restarted your app to stop the server from freezing. Your app was briefly unavailable.
What to do: Look for what is holding memory. Caches that never expire and memory leaks are the usual causes. Or move to a plan with more memory.

An app that keeps crashing and recovering

Title: Service Crashed
When it appears: Your app crashed several times and restarted itself each time, so it stayed up. A repeating pattern means something in the app keeps failing.
What to do: Open the logs for this app and look at what it prints just before each crash.

Note: Memory and CPU are checked every 2 minutes, and an incident is raised only when the limit is passed in 3 checks in a row, so a short spike does not create an incident. These limits are the defaults and can change.

How often an incident repeats

InsightX records one incident per kind, per resource, in a time window, so a condition that lasts all day does not fill the list with copies of itself.

Incident	One incident per
SSL certificate expiring or expired	24 hours
Disk getting full or almost full	6 hours
High CPU, high memory, critical memory, server out of memory, app restarted to protect its server	30 minutes
An app that keeps crashing and recovering	6 hours
A crash or a failing health check	30 minutes per service