View project and Pack events

A Kubernetes event is a message about a resource state or an operation, such as pod scheduling, image retrieval, disk attachment, or a container start failure. The Events page has two views: the project view shows events from connected namespaces, while the Pack view shows only events associated with that Pack's resources.

Events differ from application logs. An application or container writes its logs. An event describes a resource state or a decision made by a Kubernetes controller.

The project must be connected to an active cluster and have at least one connected namespace. The page and its events also depend on your role permissions.

Kubernetes events are temporary, and their retention period depends on the cluster settings. This page is not a permanent archive, so older events may no longer appear.

Kubchi fetches events when the page opens and does not refresh them automatically. Reload the page to see new events or an updated Last seen value.

From the main Kubchi sidebar, select Events. This view shows events from namespaces connected to the current project.

Use it to find the affected namespace and resource. If an event belongs to a Pack, open that Pack to narrow the list and make its messages easier to inspect.

Open the Pack, then select Events from the Pack sidebar. This view shows events that Kubchi associates with the Pack's resources.

Each row shows one event with these fields:

• Namespace: the namespace where the event was recorded.
• Subject: the resource type and name, such as Pod app-0 or Deployment app.
• Last seen: when the event was last recorded. This is not necessarily when the problem began.
• Event type: usually Normal for routine activity or Warning for a condition that needs investigation.
• Reason: a short technical identifier such as Scheduled, Pulled, or FailedMount.
• Message: details about the operation or error.

You can search and sort the table. Start with Warning events, then read the Subject, Reason, and Message together.

Start with the newest events. Subject identifies the affected resource, while Reason names the step that failed. Message often includes the dependent resource or more details from Kubernetes.

After identifying the resource, inspect it on the Workloads page. For an error inside the application or container, read the pod logs for the same period. If the event may be related to resource usage, compare it with Pack monitoring.

The Events page is read-only. It does not create, edit, or delete events.

An event is an operational message about a Kubernetes resource and often explains a state change or failed operation. An alert becomes active when a monitoring rule matches and may combine several metrics or states.

For example, an image retrieval failure may create a Warning event. An application that remains unavailable for an extended period may trigger a monitoring alert.

The namespace may not have any current events, or older events may have expired. The Pack view also includes only events associated with that Pack's resources. Check the project view and confirm that the namespace is connected to the project.

Kubchi associates events with a Pack by resource name. A resource with a custom name may be missing from the Pack view, while a resource with a similar name may appear in it. Search the project view by namespace, Subject, or Reason, then compare the resource name with the Pack's workloads and pods.

Reload the page. If the error continues, check the project connection and your permission to view events. Send the project name, namespace, and time of the failure to support or a cluster administrator.