> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Monitoring and Health

Once the deployment is running, here's how to check its status and health.

## From Your Customer Portal

Your Customer Portal provides an at-a-glance view of appliance health, including status indicators (Healthy, Degraded, Unhealthy), recent activity, and quick actions. You can also view deployed infrastructure, review and approve operations, and configure release windows.

## From Your Infrastructure

<Tabs>
  <Tab title="Kubernetes">
    **Check controller status:**

    ```bash theme={null}
    kubectl get pods -n <namespace>
    ```

    **View controller logs:**

    ```bash theme={null}
    kubectl logs -n <namespace> <controller-pod-name>
    ```

    **Check resource usage:**

    ```bash theme={null}
    kubectl top pods -n <namespace>
    ```

    **View recent events:**

    ```bash theme={null}
    kubectl get events -n <namespace> --sort-by='.lastTimestamp'
    ```
  </Tab>

  <Tab title="AWS">
    **Check instance status:**

    ```bash theme={null}
    aws ec2 describe-instance-status --instance-ids <instance-id>
    ```

    **View system logs:**

    Access via the AWS console under EC2 - Instances - your instance - Monitor and troubleshoot - Get system log.
  </Tab>
</Tabs>

## Application Telemetry

If you and we agree to enable application telemetry, the controller can forward operational metrics to our monitoring systems. This enables us to proactively detect issues and provide better support.

**What gets forwarded (when enabled):**

* Application health metrics (uptime, error rates)
* Resource utilization (CPU, memory)
* Deployment status changes

**What is never forwarded:**

* Your secrets or credentials
* Your other workloads' metrics
* Network traffic data
* User data processed by the application

Telemetry is off by default and only enabled when both parties agree.

## Health Checks

The controller performs regular health checks on the application:

* **Pod readiness** - Are the application containers running and ready to serve traffic?
* **Liveness** - Is the application responding to health probes?
* **Connectivity** - Can the controller communicate with our systems?

If a health check fails, the controller can take automatic remediation actions (like restarting a pod).

## Alerting

We monitor the controller's connectivity from our side. If the controller goes offline or reports errors, we're aware and can reach out proactively. You don't need to set up monitoring for the controller itself - that's our responsibility.

For monitoring the application's business logic and user-facing behavior, use your existing monitoring tools. The application runs in your infrastructure like any other workload.