zhiheng-zhang-Mera/dsh-health-scheduler ↗★ 0

dsh-health-scheduler

Health monitoring, pressure scoring, maintenance scheduling and action decisions for DeepSeek Harness. It never restarts anything itself. 用于系统状态监控与维护决策。适合需要监控运行压力、合理调度维护任务的系统。

Package
dsh-health-scheduler
Compatibility
Unverified
Harness peer range
^0.1.1-rc.1
Cordis peer range
^4.0.1
Version
0.1.0
License
MIT
Last updated
Sep 15, 2026

Install

$npx -p @deepseek-ai/dsh dsh plugin --profile web add github:zhiheng-zhang-Mera/dsh-health-scheduler

Configuration

Configuration is a partial document. It is deep-merged onto the selected preset, so every leaf you omit comes from the preset; arrays replace rather than merge. The plugin registers the settings namespace health-scheduler when the profile provides a settings service, and runs from the bundle patch alone when it does not.

One caveat belongs here rather than in the configuration reference: the profile patch layer is not a deep merge. A cordis.patch.yml row replaces the targeted row's whole config, so an override that restates only part of a nested object loses the rest. The deep merge described in this section applies to the document the plugin actually receives. See What the bundle contributes.

The complete key-by-key reference, including the stats-file format and the command-probe format, is in docs/configuration.md.

GroupKeysDefault
Masterenabled, presettrue, balanced
samplingintervalMs, trendIntervalMs, summaryIntervalMs, providerBackoffMs, providerBackoffMaxMs15 s, 60 s, 300 s, 30 s, 600 s
windowsrawMs, windowsMs, aggregateBucketMs, aggregateRetentionMs, dailyRetentionMs30 min, [5m,30m,2h,6h], 5 min, 24 h, 14 d
trendminSamples, minSpanMs, minRSquared3, 5 min, 0.5
weightstime, thermal, memory, runtime, worker, computer_use_ui0.15 / 0.20 / 0.25 / 0.15 / 0.15 / 0.10
thresholdsone {enter, exit} band per action55/45, 70/60, 80/68, 95/85
metricsper canonical metric: band, weight, sustainMs, trendPointsPerHour, trendCapsee docs/metrics.md
cooldownsthrottleMs, maintenanceMs, escalationMs5 min, 30 min, 60 min
throttleconcurrencyLimit, concurrencyFactornull, 0.5
maintenanceenabled, targetTime, windowStart, windowEnd, maxDeferMs, urgentOverridePressure, allowAppRestart, safePointRequiredfalse, 04:00, 03:30, 05:00, 60 min, 92, true, true
antiFlapminStateDwellMs, minRepeatActionMs, debounceEvaluations120 s, 10 min, 2
resilienceproviderFailureLimit, providerRetryAfterBackoff, reportDegradedCapability3, true, true
storageenabled, directory, maxLogBytes, maxRecentDecisionstrue, null, 4 MiB, 50
ProvidersdisabledProviders, providerOptions[], see docs

A configuration that cannot be acted on is rejected loudly. resolveConfig throws a ConfigError naming the dotted path; the plugin's apply catches it, logs it and continues on the balanced preset rather than failing the boot.

How much history you get

Three horizons, all bounded, all configurable:

HorizonWhereDefaultAnswers
Raw sampleswindows.rawMs30 min, raised to the longest windowsMs entryPercentiles, slopes, consecutive-band duration.
Aggregate bucketswindows.aggregateRetentionMs, aggregateBucketMs24 h, 5 min bucketsLong-horizon movement without keeping raw points.
Daily summarieswindows.dailyRetentionMs14 days"Was last Tuesday worse than today?" — one {count, mean, max, min} per metric per local day.

Daily summaries are rolled up from the aggregate buckets on demand, so their cost is proportional to the number of buckets, not to uptime. They are published on every HealthSnapshot as dailySummaries and in the JSON payload as daily_summaries, and they are frozen at local midnight boundaries so a day is comparable across a DST change.

ok presets/schema.json matches the configuration schema