# Alternative Checks You Can Perform Using Kubernetes Probes: Beyond HTTP Endpoints

> Discover alternative Kubernetes probes beyond HTTP. Learn to use exec commands, TCP sockets, and gRPC health checks to ensure container health and reliability.

- Repository: [Anil Kumar/DevOps-Interview-Guide](https://github.com/litu54/DevOps-Interview-Guide)
- Tags: how-to-guide
- Published: 2026-08-10

---

**Kubernetes probes support exec commands, TCP sockets, gRPC health checks, startup probes, and custom HTTP headers to verify container health without relying solely on HTTP GET requests.**

While HTTP GET probes are the most common implementation, the Kubernetes probe ecosystem offers several alternative mechanisms for assessing container health. According to the interview questions documented in the `litu54/DevOps-Interview-Guide` repository—specifically in the JPMorgan DevOps SRE guide—understanding these alternative checks is critical for production-grade container orchestration. This article explores the different probe types you can implement to perform comprehensive health validation beyond simple actuator endpoints.

## Types of Alternative Kubernetes Probe Checks

The Kubernetes API defines multiple probe handlers that execute different validation strategies. Each type serves specific use cases where HTTP checks may be insufficient or inappropriate.

### Exec Probes for Command-Based Validation

**Exec probes** execute a command inside the container and evaluate the exit code to determine health status. This approach is ideal when you need to verify file existence, check process status, or run custom validation scripts.

According to [`JPMorgan/DevOps_SRE.md`](https://github.com/litu54/DevOps-Interview-Guide/blob/main/JPMorgan/DevOps_SRE.md), interview candidates are expected to know that you can perform file-system checks like `test -f /tmp/ready` or process-level validation using `pgrep myservice`. An exit code of 0 indicates success, while any non-zero code marks the container as unhealthy.

```yaml
livenessProbe:
  exec:
    command: ["/bin/sh", "-c", "curl -f http://localhost:8080/health || exit 1"]
  initialDelaySeconds: 15
  periodSeconds: 10

```

### TCP Socket Probes for Port Connectivity

**TCP socket probes** attempt to open a TCP connection to a specified container port. This method is particularly valuable when running services that listen on specific ports but do not expose HTTP endpoints, such as databases or internal TCP APIs.

As noted in [`Others/DevOps_Engineer_4.md`](https://github.com/litu54/DevOps-Interview-Guide/blob/main/Others/DevOps_Engineer_4.md), which discusses different ways to specify probes, TCP checks ensure that a service is actually listening on its configured port before Kubernetes routes traffic to it.

```yaml
readinessProbe:
  tcpSocket:
    port: 5432
  initialDelaySeconds: 5
  periodSeconds: 5

```

### gRPC Health Check Probes (Kubernetes 1.20+)

**gRPC probes** call the standard `grpc.health.v1.Health` service to verify the status of gRPC servers. Available since Kubernetes 1.20, this probe type eliminates the need for sidecar HTTP-to-gRPC translation layers.

The probe connects to the specified port and service name, returning healthy only when the gRPC server reports a SERVING status. This is documented as an advanced check type in enterprise interview guides like those found in the repository.

```yaml
livenessProbe:
  grpc:
    port: 50051
    service: "myservice"
  initialDelaySeconds: 10
  periodSeconds: 10

```

### Startup Probes for Slow-Starting Containers

**Startup probes** disable liveness and readiness checks until a container completes its initialization sequence. This prevents Kubernetes from killing containers that require extended startup time for data loading, migration scripts, or cache warming.

The [`SquareOps/DevOps_Engineer.md`](https://github.com/litu54/DevOps-Interview-Guide/blob/main/SquareOps/DevOps_Engineer.md) file references the importance of inspecting probe configurations to handle containers with variable boot times. By configuring a startup probe with a high `failureThreshold`, you allow the application to start without interference from aggressive liveness probes.

```yaml
startupProbe:
  exec:
    command: ["sh", "-c", "test -f /tmp/started"]
  failureThreshold: 30
  periodSeconds: 10

```

### HTTP GET with Custom Headers

While technically an HTTP probe, using **custom headers** transforms the basic health check into an authenticated endpoint validator. You can include authorization tokens, API versioning headers, or content negotiation parameters to ensure the application is truly ready to serve traffic.

This approach addresses the specific scenario mentioned in [`Sony/DevOps_Engineer.md`](https://github.com/litu54/DevOps-Interview-Guide/blob/main/Sony/DevOps_Engineer.md), where debugging requires distinguishing between probe failures and actual application errors that occur despite passing basic connectivity tests.

## Practical Implementation Examples

When implementing these alternative checks, combine probe types with appropriate timing parameters to avoid false positives. The repository's interview questions emphasize understanding how `failureThreshold` and `periodSeconds` interact to detect intermittent failures while keeping pods alive during temporary issues.

The following configuration demonstrates combining multiple probe types for a comprehensive health-checking strategy:

```yaml

# Exec probe for custom validation logic

livenessProbe:
  exec:
    command: ["pgrep", "myservice"]
  initialDelaySeconds: 10
  periodSeconds: 15

# TCP probe for database connectivity

readinessProbe:
  tcpSocket:
    port: 5432
  initialDelaySeconds: 5
  periodSeconds: 5

# Startup probe for initialization completion

startupProbe:
  exec:
    command: ["test", "-f", "/tmp/initialization-complete"]
  failureThreshold: 30
  periodSeconds: 10

```

## Summary

- **Exec probes** run commands inside containers to validate file systems, processes, or custom logic, as demonstrated in [`JPMorgan/DevOps_SRE.md`](https://github.com/litu54/DevOps-Interview-Guide/blob/main/JPMorgan/DevOps_SRE.md).
- **TCP socket probes** verify port binding without requiring HTTP protocols, useful for databases and internal services.
- **gRPC probes** provide native health checking for gRPC services since Kubernetes 1.20, eliminating HTTP bridge requirements.
- **Startup probes** protect slow-starting containers from premature termination by deferring liveness checks during initialization.
- **Custom HTTP headers** enable authenticated and version-specific health validation beyond simple endpoint checks.

## Frequently Asked Questions

### What is the difference between liveness and readiness probes?

**Liveness probes** determine when to restart a container, killing the pod if the check fails to resolve application deadlocks. **Readiness probes** control traffic routing to a pod, removing it from service endpoints when the application is temporarily unable to serve requests. As referenced in [`Verizon/DevOps_Engineer.md`](https://github.com/litu54/DevOps-Interview-Guide/blob/main/Verizon/DevOps_Engineer.md), both probe types use the same handler mechanisms (exec, HTTP, TCP) but serve distinct orchestration purposes.

### When should I use an exec probe instead of an HTTP probe?

Use **exec probes** when your application lacks an HTTP server, requires file-system validation, or needs process-level verification that cannot be exposed through a web endpoint. Exec probes are also necessary when checking dependencies that don't expose HTTP interfaces, such as verifying background worker processes with `pgrep` or confirming configuration file presence before startup.

### How do startup probes prevent premature container termination?

**Startup probes** override all other probes until they succeed, allowing containers with long initialization sequences to complete startup without being killed by liveness checks. By setting a high `failureThreshold` (e.g., 30 checks with 10-second periods), you give the container five minutes to initialize while Kubernetes waits before enforcing standard liveness policies.

### Are gRPC probes supported in all Kubernetes versions?

No, **gRPC probes** require Kubernetes 1.20 or later. Prior versions require using an exec probe to call a gRPC client or implementing an HTTP health endpoint that translates to gRPC status. When running on older clusters, you must use alternative methods such as exec probes with custom gRPC client binaries as suggested in the repository's interview materials.