If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/Xabaril/AspNetCore.Diagnostics.HealthChecks shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 2w ago
• 28+ active contributors
• Distributed ownership (top contributor 28% of recent commits)
• Apache-2.0 licensed
• CI configured
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live Xabaril/AspNetCore.Diagnostics.HealthChecks repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Xabaril/AspNetCore.Diagnostics.HealthChecks.

What it runs against: a local clone of Xabaril/AspNetCore.Diagnostics.HealthChecks — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in Xabaril/AspNetCore.Diagnostics.HealthChecks | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 45 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Xabaril/AspNetCore.Diagnostics.HealthChecks. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Xabaril/AspNetCore.Diagnostics.HealthChecks.git
#   cd AspNetCore.Diagnostics.HealthChecks
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of Xabaril/AspNetCore.Diagnostics.HealthChecks and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Xabaril/AspNetCore.Diagnostics.HealthChecks(\\.git)?\\b" \\
  && ok "origin remote is Xabaril/AspNetCore.Diagnostics.HealthChecks" \\
  || miss "origin remote is not Xabaril/AspNetCore.Diagnostics.HealthChecks (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 45 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~15d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/Xabaril/AspNetCore.Diagnostics.HealthChecks"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

AspNetCore.Diagnostics.HealthChecks is a comprehensive .NET NuGet package ecosystem that provides pre-built health checks for 50+ external services (AWS, Azure, SQL databases, message queues, Kubernetes, etc.) and a web UI dashboard to visualize application and dependency health status in real-time. It transforms ASP.NET Core's native health check middleware into an enterprise-grade monitoring solution with storage persistence, webhooks, and historical timeline tracking. Monorepo with per-service health check packages under src/ (e.g., src/HealthChecks.Aws.S3/, src/HealthChecks.Azure.BlobStorage/) each with its own .csproj, plus a shared UI package (HealthChecks.UI), sample applications in samples/, and automated workflows (40+ .github/workflows/ files) triggering CI/CD per package. .config/dotnet-tools.json manages local tooling (likely Cake or similar build automation).

.NET backend engineers and platform teams operating ASP.NET Core applications who need to monitor the health of dozens of microservice dependencies (databases, cloud services, message brokers) without writing custom diagnostic code, and ops/SRE teams who need a central dashboard to observe application status across Kubernetes clusters.

Production-ready and actively maintained: the repo has 1.4M lines of C# code, extensive CI/CD workflows for 40+ independent health check packages (each with CI, CD, and preview CD stages in .github/workflows/), codecov integration for coverage tracking, and regular commit activity. Supports ASP.NET Core 8.0 down to 2.2 with deliberate version maintenance branches (netcore-3.1, netcore-3.0, netcore-2.2).

Low risk for core functionality but moderate operational complexity: the repo's monorepo pattern means 50+ independently-versioned packages with their own dependency chains (AWS SDK, Azure SDK, various database drivers), creating a large transitive dependency surface. No obvious single-maintainer bottleneck visible (contributors badge present), but the breadth of supported services means breaking changes in upstream SDKs require coordinated updates across many packages. Last visible activity indicates active development.

Active development of health check packages with parallel CI, CD (production), and CD preview (staging) pipelines for each service integration (ApplicationStatus, ArangoDB, AWS S3/SNS/SQS/SecretsManager/SystemsManager, Azure BlobStorage/DigitalTwin/FileStorage/IoTHub/QueueStorage/Tables/ApplicationInsights/EventHubs/KeyVault visible in workflows). The three-tier CI/CD strategy and preview deployments suggest active feature rollout and testing.

Clone and build the monorepo: git clone https://github.com/Xabaril/AspNetCore.Diagnostics.HealthChecks.git && cd AspNetCore.Diagnostics.HealthChecks && dotnet restore && dotnet build. The .config/dotnet-tools.json indicates local tool setup via dotnet tool restore. Individual sample applications under samples/ can be run with dotnet run after navigating to their directories.

Daily commands: After dotnet restore && dotnet build, run sample apps with dotnet run from samples/HealthChecks.Sample/ or similar. The .env file suggests environment variable configuration for cloud service credentials (AWS, Azure keys likely). CI runs via GitHub Actions workflows which execute dotnet test and dotnet pack commands (inferred from CD workflow naming).

• .github/workflows/: 40+ workflow files establish the package-per-service release strategy; examine one (e.g., healthchecks_aws_s3_ci.yml) to understand build, test, and publish automation
• .config/dotnet-tools.json: Declares local development tools; run dotnet tool restore to bootstrap build environment
• src/HealthChecks.UI/: Central dashboard application; contains ASP.NET Core controller/views (TypeScript/CSS/HTML for UI) and storage provider abstractions
• src/HealthChecks.Aws.S3/: Canonical example of a service-specific health check package; shows IHealthCheck implementation, extension methods, and test patterns
• .editorconfig: Enforces code style across C#, TypeScript, CSS; required reading before submitting PRs
• samples/: Runnable example applications demonstrating health check registration and UI integration; start here to understand end-to-end usage

To add a health check for a new service: create a new directory under src/HealthChecks.ServiceName/, model it after an existing package like src/HealthChecks.Aws.S3/ (implement IHealthCheck, create extension methods), add unit tests under tests/, and create a .github/workflows/healthchecks_servicename_ci.yml workflow following the 3-file pattern (CI, CD, CD preview). UI dashboard changes go in src/HealthChecks.UI/ and its TypeScript/CSS under UI folders. Use .editorconfig for code style consistency.

1. Each health check package requires valid credentials for its service (AWS_ACCESS_KEY_ID, AZURE_SUBSCRIPTION_ID, etc.) in .env to run integration tests locally; check CI workflows for mock/stub patterns if real credentials unavailable. 2) The UI package has TypeScript/CSS build steps (23K TypeScript lines) that may require npm install in the UI directory before dotnet build succeeds. 3) Breaking changes in upstream SDKs (AWS SDK v2→v3, Azure SDK major versions) can cascade across multiple packages; check GitHub Issues for known incompatibilities. 4) The three-tier CI/CD pattern (CI, CD production, CD preview) means some workflows push to preview registries—verify you're publishing to the correct NuGet feed.

• IHealthCheck interface pattern — Core abstraction in this repo; understanding how to implement CheckHealthAsync() and return HealthCheckResult is required to create new service integrations or customize health logic
• Health check publishers / IHealthCheckPublisher — Mechanism to push health status to external systems (webhooks, application insights); central to the HealthChecks.UI notification and history-timeline features
• NuGet package versioning and transitive dependencies — This monorepo maintains 50+ independently-versioned packages; understanding SemVer, dependency ranges, and SDK compatibility across versions (ASP.NET Core 2.2→8.0) prevents broken installations
• GitHub Actions matrix builds and multi-stage CI/CD — The 40+ workflow files use matrix strategies to test against multiple frameworks and cloud SDKs; understanding how .github/workflows/ orchestrate preview vs. production releases is essential for contributing new service packages
• Circuit breaker and bulkhead patterns — Health checks often guard against cascading failures; understanding how to design timeout and retry logic in check implementations prevents thundering-herd failures
• Microservices observability and synthetic health probes — Health checks serve as synthetic probes in Kubernetes liveness/readiness probe systems and multi-tier service monitoring; knowing where and when to probe (app startup, steady-state, degradation) affects deployment reliability
• Repository-as-a-platform monorepo strategy — This repo uses a shared-code monorepo with per-package workflows, shared UI, and centralized tooling; understanding directory layout, build isolation, and dependency sharing prevents conflicts when adding new integrations

• dotnet/AspNetCore — Official ASP.NET Core repository; this project extends the native IHealthCheck interface and Endpoint middleware that live upstream
• prometheus-net/prometheus-net — Complements health checks by exporting metrics to Prometheus for time-series health monitoring and alerting
• serilog/serilog-aspnetcore — Often paired with health checks to correlate structured logging with health status changes and dependency failures
• App-vNext/Polly — Resilience and transient-fault-handling library frequently integrated with health checks to implement retry/circuit-breaker logic for checked dependencies
• davidfowl/Monitoring-Lab — Reference implementation demonstrating health checks, distributed tracing, and metrics in a unified observability pipeline

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add missing CI/CD workflow files for incomplete health check packages

The .github/workflows directory shows a pattern of *_ci.yml, *_cd.yml, and *_cd_preview.yml files for each health check package. Analyzing the file list, several packages appear to have incomplete workflow coverage (missing one or more workflow files). This is critical for maintaining consistent automated testing and deployment across all 50+ health check packages. A contributor could identify which packages are missing workflows and add them following the established pattern.

• [ ] Audit .github/workflows/ directory to identify packages with incomplete workflow triplets (ci, cd, cd_preview)
• [ ] Document which specific packages are missing which workflow files (e.g., 'healthchecks_dynamodb_*.yml')
• [ ] Create missing workflow files by copying and adapting existing similar package workflows
• [ ] Ensure all workflow files follow the naming convention: healthchecks_{package}_{stage}.yml
• [ ] Test that workflows trigger correctly on pull requests and merges

Create comprehensive integration test suite for core health check providers

With 50+ health check packages (AWS, Azure, databases, message queues, etc.), there's likely limited test coverage for the core health check registration and execution logic. A contributor could create a structured test project that validates health check initialization, status transitions (Healthy/Degraded/Unhealthy), and timeout handling across multiple providers without requiring external service dependencies.

• [ ] Create new test project: src/HealthChecks.Core.Tests/ or similar
• [ ] Write unit tests for health check result aggregation and status determination
• [ ] Add tests for timeout and cancellation token scenarios
• [ ] Create mock implementations for common external services to enable deterministic testing
• [ ] Add tests validating the health check response format (JSON structure, tags, descriptions)

Consolidate and deduplicate CI/CD workflow logic into reusable GitHub Actions

The repository contains 150+ workflow files (.yml) following nearly identical patterns (one triplet per package: ci, cd, cd_preview). This creates maintenance burden and inconsistency risk. A contributor could extract common workflow logic into custom GitHub Actions (stored in .github/actions/) and refactor the repetitive workflows to call these actions with different parameters, significantly reducing code duplication and improving maintainability.

• [ ] Analyze 5-10 existing workflow files to identify common patterns and shared steps
• [ ] Create reusable GitHub Actions in .github/actions/ directory for: test execution, package building, NuGet publishing, Docker image building
• [ ] Refactor existing *_ci.yml workflows to use the new test action with package-specific parameters
• [ ] Refactor existing *_cd.yml and *_cd_preview.yml workflows to use publishing actions
• [ ] Document the new action structure in .github/README.md for future maintainers

• Add health check tests for timeout scenarios in a service package (e.g., src/HealthChecks.Aws.S3/) that currently lack IHealthCheckPublisher integration for custom failure notifications; examine .github/workflows/healthchecks_aws_s3_ci.yml to see what test patterns exist and replicate them.
• Expand TypeScript types in the HealthChecks.UI dashboard (src/HealthChecks.UI/ has 23K TypeScript) to eliminate 'any' types in webhook configuration interfaces; this improves developer experience when configuring failure notifications.
• Write documentation for a new service health check (e.g., verify if HealthChecks.Gcp exists; if not, open an enhancement issue and contribute the package following the AWS S3 pattern) with sample code in samples/ and a .github/workflows/healthchecks_gcp_*.yml CI/CD template.

• Critical · Hardcoded Database Password in docker-compose.yml — docker-compose.yml - sqlserver service, SA_PASSWORD environment variable. The SQL Server service contains a hardcoded password 'Password12!' in the docker-compose.yml file. This exposes sensitive credentials in version control and makes the system vulnerable to unauthorized access. Fix: Move the password to a .env file (which should be in .gitignore), use Docker secrets for production, or leverage a secrets management system like AWS Secrets Manager or Azure Key Vault.
• High · Outdated Elasticsearch Version — docker-compose.yml - elasticsearch service. The docker-compose.yml specifies Elasticsearch version 6.3.2, which is extremely outdated (released in 2018) and contains numerous known security vulnerabilities. This version is no longer supported and lacks critical security patches. Fix: Update to the latest stable Elasticsearch version (8.x or later) and regularly maintain dependency versions. Implement a dependency update policy.
• High · Unrestricted Dependency Versions in Cargo.toml — Cargo.toml - serde and serde_derive dependencies. The Rust package dependencies use wildcard versions (e.g., 'serde = "*"') which allows any version to be installed. This could introduce breaking changes or security vulnerabilities without explicit control. Fix: Specify explicit version ranges using semantic versioning (e.g., 'serde = "^1.0"') and regularly audit dependencies using 'cargo audit' for known vulnerabilities.
• High · Outdated Async Runtime Library — Cargo.toml - async-std dependency. async-std version 1.0 is outdated and no longer actively maintained. The ecosystem has largely moved to tokio. This may impact security updates and compatibility. Fix: Consider migrating to tokio runtime or update async-std to the latest maintained version. Regular dependency audits should be performed.
• Medium · Environment File (.env) May Contain Secrets — .env file. The presence of a .env file in the repository root suggests environment variables containing sensitive information may be tracked in version control. The file listing doesn't confirm if it's in .gitignore. Fix: Ensure .env is in .gitignore. Never commit secrets to version control. Use environment-specific configuration management or secrets management systems.
• Medium · Docker Services Without Resource Limits — docker-compose.yml - all services. The docker-compose.yml services lack resource constraints (memory and CPU limits), making the system vulnerable to resource exhaustion attacks and denial of service. Fix: Add 'mem_limit', 'cpus', and 'memswap_limit' constraints to each service to prevent resource exhaustion.
• Medium · Elasticsearch Port Exposed on 0.0.0.0 — docker-compose.yml - elasticsearch service ports. Elasticsearch is exposed on port 9200 without apparent network segmentation. By default, Elasticsearch has no authentication, making it vulnerable to unauthorized access. Fix: Restrict port exposure to localhost or specific networks using 'ports: "127.0.0.1:9200:9200"' in development. Enable Elasticsearch security features in production (X-Pack, authentication).
• Medium · Redis Without Authentication — docker-compose.yml - redis service. Redis service is exposed without any authentication mechanism, making it vulnerable to unauthorized access and potential data theft or manipulation. Fix: Run Redis with requirepass configuration, bind to localhost only in development, use network policies, and consider using Redis Cluster with authentication in production.
• Medium · Incomplete Docker Compose Configuration — docker-compose.yml - end of file. The docker-compose.yml snippet is truncated at the clickhouse service definition, suggesting incomplete or hidden configuration that may contain additional security issues. Fix: Complete and review the entire docker-compose.yml file for security misconfigurations.
• Low · HTTP-Only Solr Service — undefined. The Solr service is exposed without explicit HTTPS or authentication configuration, potentially vulnerable to man-in-the- Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.