@healthzkit/valkey package ships ready-made HealthAdapter implementations for common Valkey Node.js clients. Each adapter measures round-trip latency, returns ok with metadata.latencyMs (and any extra fields from an optional hook), or fail with the caught error.
Install the adapter package and at least one peer client library:
Shared options
Every factory accepts a small common shape (seeBaseValkeyOptions in the package):
iovalkeyAdapter
Peer: iovalkey >= 0.3.
Use either a shared Redis instance or a connection string (the adapter lazily creates an internal client with maxRetriesPerRequest: 1 and enableReadyCheck: false, merged with your options).
client.call(...) as a single string (for example "PING" or "ECHO x").
glideValkeyAdapter (Valkey GLIDE)
Peer: @valkey/valkey-glide >= 1.
Use a GlideClient instance (with customCommand) or a connection string. For connection strings, the adapter parses redis://, rediss://, valkey://, and valkeys:// URLs into GlideClientConfiguration, then calls GlideClient.createClient once and reuses the client.
rediss://andvalkeys://enable TLS (default port 6380 when omitted).redis://andvalkey://use plain TCP (default port 6379 when omitted).- URL credentials map to
credentials.username/credentials.password. - A path such as
/2setsdatabaseId.
command string is split on whitespace and passed to customCommand as an argv array (default ["PING"]; custom example "ECHO hello" → ["ECHO", "hello"]).
Subpath imports
Import only the client you install so unused peers are not pulled in:
All adapters are also re-exported from
@healthzkit/valkey.
Wiring into createHealthKit
Treat each factory’s return value as adapter on a check (same as a hand-written { check() { ... } } object):
schedule on the check if you want cached readiness results instead of hitting Valkey on every probe (see Scheduling).