YuptimeKubernetes-native Monitoring

Quick Start ​

The Timoni module under timoni/yuptime/ is the authoritative packaging source for this repository. The checked-in k8s/, helm/yuptime/, and manifests/ trees are mirrors kept aligned from that CUE-first workflow.

timoni apply yuptime oci://ghcr.io/briansunter/yuptime/timoni-module \
  --version latest \
  --namespace yuptime

helm install yuptime oci://ghcr.io/briansunter/yuptime/charts/yuptime \
  --namespace yuptime \
  --create-namespace

kubectl apply -f https://raw.githubusercontent.com/briansunter/yuptime/master/k8s/crds.yaml
kubectl create namespace yuptime
kubectl apply -f https://raw.githubusercontent.com/briansunter/yuptime/master/manifests/all.yaml -n yuptime

Then create a simple HTTP monitor:

apiVersion: monitoring.yuptime.io/v1
kind: Monitor
metadata:
  name: website-health
  namespace: yuptime
spec:
  type: http
  schedule:
    intervalSeconds: 60
    timeoutSeconds: 30
  target:
    http:
      url: "https://example.com"
  successCriteria:
    http:
      acceptedStatusCodes: [200]

Monitor Types ​

Yuptime currently exposes 17 monitor enum values. docker is reserved but not implemented; the rest map to active checkers or protocol-specific validation flows.

Why Yuptime? ​

• Configuration is stored in Kubernetes resources, not a separate database.
• The controller only writes to status subresources.
• Each check runs in an isolated Job pod.
• Metrics, health, and readiness endpoints are exposed on port 3000.

Read the getting started guide →