v1.7.8

Watchdog v1.7.8

Kubernetes-ready deployment

• Added an official Helm chart for running Watchdog as a finite Kubernetes CronJob, matching its one-shot execution model.
• Added persistent state support through a PVC, with support for an existing claim or ephemeral state when persistence is intentionally disabled.
• Added safe Secret integration through envFromSecret; secrets are never placed in Helm values or ConfigMaps.
• Added an opt-in manual Kubernetes Job for commands such as configuration validation.
• Added image digest support for immutable container deployments.

Security hardening

• Kubernetes workloads now run as a non-root user with a read-only root filesystem.
• Enabled RuntimeDefault seccomp, dropped Linux capabilities, disabled privilege escalation, service-account token mounting, host networking, privileged mode, and Docker socket access.
• Documented remote HTTP remediation as the Kubernetes-compatible remediation mechanism.

CI, tests, and documentation

• Added a dedicated Kubernetes GitHub Actions workflow with Helm linting, rendered-chart validation, and real kind-cluster integration tests.
• Added tests for CronJob execution, persistent state, Docker-socket absence, and invalid configuration exit handling.
• Added a Kubernetes workflow badge to the README.
• Added Helm usage examples, a Kubernetes deployment Wiki page, an architecture decision record, release instructions, and updated AI contributor guidance.

Upgrade notes

Kubernetes deployment requires Kubernetes 1.31 or later. The default Helm release is suspended until you provide a real Watchdog configuration and explicitly enable its schedule.

v1.7.7

small text additions

v1.7.6

Watchdog v1.7.6

Added

• Added opt-in HTTP transport support for private CA bundles and mutual TLS (mTLS) client authentication.
• Added per-check HTTP(S) proxy support for standard HTTP checks, liveness checks, and readiness checks.
• Added proxy authentication through paired environment variables, keeping credentials out of YAML and curl command-line arguments.
• Added validation for certificate paths, client certificate/key pairs, proxy URLs, environment variable names, and forbidden embedded proxy credentials.
• Added a ready-to-adapt mTLS and authenticated proxy example configuration.
• Added regression coverage for templates, liveness/readiness transport settings, validation failures, and secret non-disclosure.

Security

• TLS hostname and certificate verification remain enabled by default.
• Proxy credentials are written only to a temporary mode-0600 curl configuration file and are never stored in logs, state, metrics, history, or status pages.
• Encrypted client private keys are intentionally not supported, preventing passphrases from being exposed through process arguments.

v1.7.5

Watchdog v1.7.5

Highlights

• Added an opt-in Prometheus scheduler heartbeat metric to detect missed Watchdog runs independently of monitored service health.
• Added ready-to-use observability assets: a Grafana dashboard, Prometheus alert rules, and an Alertmanager routing example.
• Added safe, limited JSON assertions for HTTP checks with typed scalar and regex matching.
• Added per-service notification channel routing, plus optional severity and runbook context for PagerDuty and Opsgenie.
• Introduced a production-ready Docker distribution with non-root images, multi-architecture GHCR publishing, optional Docker Hub publishing, SBOMs, provenance, and an optional Docker CLI variant.
• Added Docker runtime regression coverage for health checks, invalid configuration handling, graceful shutdown, and Docker socket isolation.
• Added a reusable release preflight to verify tag, version, CLI output, README archive links, changelog entry, and installer metadata before publishing.

Fixed

• Improved Docker signal forwarding so long-running checks can finish cleanup and preserve Watchdog’s documented runtime exit code instead of being forcibly terminated.

v1.7.4

Watchdog v1.7.4

Added

• Per-service notification routing with services[].notify.channels, optional severity, and runbook URLs. Services without routing configuration continue to use all globally enabled notification channels.
• Limited, opt-in JSON assertions for HTTP checks through expect.json. Assert exact typed scalar values or regex-match selected string fields using safe property and array-index paths.
• Production Docker distribution with a non-root runtime image, an optional Docker CLI variant, least-privilege Compose configuration, multi-architecture publishing, SBOMs, and provenance metadata.

Improved

• JSON response assertions use the existing bounded private response capture. Response bodies and asserted values are never written to logs, state, metrics, history, or the status page.
• Docker containers now forward stop signals through active Watchdog check processes and preserve Watchdog’s documented exit code during graceful shutdown.

Fixed

• Long-running container checks no longer end with Docker’s forced-kill exit code when stopped; Watchdog cleanup completes and returns the expected runtime result.

v1.7.2

Watchdog v1.7.2

Fixed

• Corrected release metadata so the Watchdog version, CLI output, README download links, changelog entries, and release tag validation remain consistent.
• Improved the GitHub Marketplace publishing flow by ensuring the bundled Watchdog configuration-validation Action is released with accurate version information.

GitHub Action

• The Docker-based GitHub Action validates Watchdog YAML configurations without running checks, remediation, hooks, notifications, or creating runtime state.
• Configuration files are restricted to the checked-out GitHub workspace.
• CI verifies successful validation, invalid configuration handling, and workspace-boundary protection.

Verification

• Confirmed generated distribution freshness.
• Confirmed release metadata validation for v1.7.2.

v1.7.1

Watchdog v1.7.1

Added

• A self-contained GitHub Action for validating Watchdog configurations in CI/CD.

- uses: shellharbor/watchdog@v1
  with:
    config: monitoring/watchdog.yaml

• The Action runs only service-watchdog.sh validate; it never executes checks, remediation, hooks, notifications, or writes Watchdog runtime state.
• Built-in Docker image dependencies include Bash, Mike Farah yq v4, and optional validation tools for DNS, Ping, TLS, SQLite history, and ClamAV checks.
• Configuration paths are restricted to GITHUB_WORKSPACE, preventing validation of files outside the checked-out repository.
• Added CI coverage that builds the Action container and verifies valid configurations, invalid configurations, and workspace-boundary protection.

Documentation

• Added GitHub Actions setup instructions to the README and deployment Wiki.
• Updated contributor guidance, testing conventions, and the project skill contract.

Security

• The Action container uses version-and-digest-pinned base images.
• Validation failures return exit code 2 with Watchdog’s field-specific configuration diagnostic.

v1.7.0

Watchdog v1.7.0

Added

• A self-contained GitHub Action for validating Watchdog configurations in CI/CD.

- uses: shellharbor/watchdog@v1
  with:
    config: monitoring/watchdog.yaml

• The Action runs only service-watchdog.sh validate; it never executes checks, remediation, hooks, notifications, or writes Watchdog runtime state.
• Built-in Docker image dependencies include Bash, Mike Farah yq v4, and optional validation tools for DNS, Ping, TLS, SQLite history, and ClamAV checks.
• Configuration paths are restricted to GITHUB_WORKSPACE, preventing validation of files outside the checked-out repository.
• Added CI coverage that builds the Action container and verifies valid configurations, invalid configurations, and workspace-boundary protection.

Documentation

• Added GitHub Actions setup instructions to the README and deployment Wiki.
• Updated contributor guidance, testing conventions, and the project skill contract.

Security

• The Action container uses version-and-digest-pinned base images.
• Validation failures return exit code 2 with Watchdog’s field-specific configuration diagnostic.

v1.6.0

Watchdog v1.6.0

Highlights

Watchdog v1.6.0 expands network monitoring, on-call alerting, and safe remediation capabilities while preserving its one-shot, dependency-light Bash design.

Added

• DNS checks powered by dig

  • Supports A, AAAA, CNAME, MX, NS, and TXT records.
  • Validate minimum response count and exact expected answers.
  • Optional custom resolver support.

• ICMP Ping checks powered by Linux ping

  • Monitor host reachability with configurable packet count.
  • Alert on packet-loss thresholds and optional average RTT limits.

• PagerDuty on-call notifications

  • Creates or updates incidents on failure and escalation.
  • Resolves the matching incident automatically on recovery.
  • Uses the Watchdog incident ID as the deduplication key.

• Opsgenie on-call notifications

  • Creates, escalates, and closes alerts through the Opsgenie Alert API.
  • Supports US and EU API regions.
  • Uses the Watchdog incident ID as the alert alias to prevent duplicates.

• Remote HTTP remediation via actions.http

  • Call restart, orchestration, or cloud APIs using POST, PUT, PATCH, or DELETE.
  • Configure request headers, optional request bodies, timeouts, and accepted HTTP status codes.
  • Runs after local remediation commands and respects cooldowns, backoff, maintenance windows, circuit breakers, flapping protection, verification, and --dry-run.

• HTTP remediation allowlisting

  • Enforce exact method-and-URL pairs with security.remediation_policy.allowed_http.
  • Extends enforce-mode protection without changing legacy configurations.

Security

• PagerDuty keys, Opsgenie keys, remote API headers, and request bodies can be supplied through *_env fields.
• Sensitive request data is written only to private temporary files and is never exposed through curl command-line arguments, logs, state, metrics, history, or the status page.
• DNS and Ping dependencies are checked only when their corresponding check type is enabled.

Documentation and Quality

• Added DNS/Ping, on-call notification, and remote HTTP remediation examples.
• Updated the JSON Schema for editor validation and autocomplete.
• Added negative schema fixtures and end-to-end coverage for all new functionality.
• Updated the README, Wiki, changelog, and project skill contract.

Compatibility

All new capabilities are opt-in. Existing configurations, state files, metrics, exit codes, and monitoring behavior remain unchanged.

v1.5.0

Watchdog v1.5.0

This release improves maintainability and configuration-read performance while preserving Watchdog’s portable single-file deployment model.

Highlights

• Added an in-memory configuration cache to reduce repeated yq parsing during a watchdog run.
• Split the development source into focused modules for bootstrap, configuration, notifications, checks, state handling, lifecycle logic, history, and CLI behavior.
• Kept service-watchdog.sh as the self-contained production artifact: installations, cron jobs, and systemd units continue to use the same single script without runtime module loading.
• Added scripts/build-watchdog.sh to regenerate the distribution and --check mode to detect an outdated generated script.
• Added a dedicated build regression test and CI validation to ensure the generated file always matches the modular source.
• Extended CI syntax coverage to every source module and retained ShellCheck validation for the complete generated program.
• Added an architecture decision record and updated the README, contributor guide, release guide, project AI instructions, and wiki documentation.

Upgrade notes

No configuration migration is required. Users can continue deploying service-watchdog.sh and VERSION exactly as before.