What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Yes, a Node.js API can report degraded health, but only if you separate three questions: is the process stuck, can this instance accept traffic, and is it running with reduced capability? An invalid or expired API key should almost never make the process fail its liveness check. A required dependency that the API cannot function without may justify a readiness failure. A premium-tier feature that is broken should usually produce a degraded signal, not removal of the whole instance from the load balancer.
Liveness and readiness do different jobs
Kubernetes uses liveness and readiness probes for different actions, and mixing them is the most common source of avoidable outages. A liveness failure tells the kubelet to restart the container. A readiness failure removes the Pod from Service endpoints, so it stops receiving traffic, but it is not restarted. The Kubernetes documentation on configuring liveness, readiness and startup probes describes readiness as the right signal when an application is temporarily unable to serve, for example while required data or configuration loads or while external services are unavailable.
| Probe | Kubernetes consequence | Should fail when | Should not fail when |
|---|---|---|---|
| Startup | Holds off liveness and readiness until the app has initialized | Initialization has not finished within the allowed window | A later dependency blip happens after startup succeeded |
| Liveness | Restarts the container | The event loop is blocked, the process is deadlocked, or the server cannot respond at all | A database, key store or upstream API is down, or one customer’s key is rejected |
| Readiness | Removes the Pod from Service traffic until it passes again | A dependency the API cannot serve without is unavailable | Only optional features or a single tier’s features are impaired |
The Kubernetes documentation warns that an incorrect liveness implementation can cause cascading failures. If a liveness probe checks a database that is merely slow, every Pod restarts at once, the remaining Pods absorb the load, and their probes start failing too. Restarting a Node.js process rarely fixes a database outage, so a dependency check belongs in readiness unless the process itself is broken.
Free tools Windows power users keep installed
One-click scans. No signup required.
Define the states before writing the endpoint
Write down the states in your API’s terms before choosing a URL. Three states cover most cases:
#1 Best Overall
- Live: the process can run its event loop and respond. A failure here should mean a restart is a plausible fix, such as a deadlock or a leaked resource that only a restart clears.
- Ready: this instance can serve the traffic it is configured to receive right now. A failure removes it from rotation.
- Degraded: the instance is ready, but a defined feature or request class is impaired. Traffic keeps flowing, and the impairment is visible to operators and alerting.
Keep this state model separate from the HTTP response. The probe response can be small and boring. A richer diagnostic view can exist behind authentication for operators. The Node.js Reference Architecture guidance favors minimal health endpoints for most services, and the Lightship library is a documented option that provides readiness, liveness, startup checks and graceful shutdown if you prefer not to write the routes yourself.
Where credential outcomes belong
An invalid, expired, revoked, or quota-exhausted API key is normally the result of one request being rejected. The process is working correctly when it rejects a bad key. Treating that rejection as a health problem would let one misbehaving client restart or remove capacity for everyone else.
Rank #2
The probe sources do not define credential policy, so the classification below is an architectural recommendation. Your API contract should confirm each row before you implement it.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11| Credential condition | Scope | Liveness | Readiness | Degraded signal |
|---|---|---|---|---|
| Invalid, expired or revoked key from one client | Request-level | No effect | No effect | None; log and meter the 401 or 403 |
| Client over quota or rate limit | Request-level | No effect | No effect | None; return 429 to that client |
| Client lacks entitlement for a tier-specific feature | Request class | No effect | No effect | None; return 403 for that feature |
| Credential store unreachable, and no cached validation is available | Instance-wide | No effect | Fail, if every request depends on validation | Not applicable once readiness fails |
| Credential store unreachable, but a recent validation cache can answer requests | Instance-wide, partial | No effect | Pass | Degraded, with a safe reason such as “key validation running from cache” |
The key question for the last two rows is whether the instance can still do its job. If it cannot validate any request, it is not ready. If it can validate from a cache whose age you control and monitor, it can stay in rotation while reporting the degradation.
Rank #3
Make tier-aware readiness deliberate
A premium-only dependency should not mark every instance unready for every tier if baseline requests still work. Before you write the check, list each request class and the tier that can use it. Then decide whether the probe asks “can this instance serve its core contract?” or “is this specific critical capability working?” Most APIs want the first question for readiness and the second for degraded reporting.
Overbroad readiness is expensive. Because readiness controls Service traffic, a single feature check that fails for all instances can remove the entire fleet’s capacity. Keep premium-only checks out of readiness unless the premium feature is part of what every instance must serve.
Rank #4
A minimal Express example
The following sketch shows the separation. It has not been run in production, so treat it as a starting structure and test it against your own dependencies and timeouts.
- Run dependency checks on a timer in the background, not inside each probe request, so probes stay fast and do not hammer the dependency.
- Expose
/livezwith no dependency checks, so it answers only if the process can respond. - Expose
/readyzthat returns 503 only when a required dependency is down, and returns 200 with a degraded body when an optional feature is impaired. - Point the Kubernetes liveness and readiness probes at these exact paths, and confirm the paths match the routes your service really exposes.
const express = require('express');
const app = express();
const health = {
datastore: true, // required: every request needs it
keyStore: true, // required: every request needs validation
premiumExport: true, // optional: only premium-tier requests use it
};
// Background refresh, every 10 seconds, with a timeout on each check.
setInterval(async () => {
health.datastore = await checkDatastore(2000);
health.keyStore = await checkKeyStore(2000);
health.premiumExport = await checkPremiumExport(2000);
}, 10000);
app.get('/livez', (req, res) => {
res.status(200).send('ok');
});
app.get('/readyz', (req, res) => {
if (!health.datastore || !health.keyStore) {
return res.status(503).json({ status: 'not ready' });
}
const impaired = [];
if (!health.premiumExport) impaired.push('premium-export');
res.status(200).json({
status: impaired.length ? 'degraded' : 'ready',
impaired,
});
});
app.listen(8080);The checkDatastore, checkKeyStore and checkPremiumExport functions are yours to write. Each should use a short timeout and return a boolean, not throw.
Report degradation without confusing consumers
NestJS Terminus illustrates one pattern. A degraded indicator does not fail the health check. It appears under info, the overall status reads degraded, and the HTTP status stays 200. That pattern is useful for dashboards, but it is a framework behavior, not a universal standard.
A Kubernetes HTTP probe decides only from the status code. It does not read the body, so a degraded body with a 200 keeps the Pod in rotation and gives Kubernetes no signal about the degradation. Surface degradation through metrics, logs and alerts, and confirm how your load balancer or ingress interprets status codes before relying on any body-level field.
Never place raw API keys, authorization headers, connection strings or secret values in health responses or logs. Report a safe category such as “key validation degraded” or a redacted reason. This is security practice; the probe documentation does not cover it.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Checklist before you deploy
- Each dependency is marked required or optional, with the reason written down.
- Liveness has no calls to external dependencies.
- Readiness fails only when the instance cannot serve its core contract.
- Every dependency check has a timeout shorter than the probe timeout.
- A single client’s bad credential never changes any probe result.
- Degraded states emit a metric or log entry that an alert can watch.
- Probe paths in the Kubernetes manifest match the routes in code.
- Health responses contain no secrets.
Troubleshooting common mistakes
- Pods restart during a database outage: a dependency check has moved into liveness. Move it to readiness, and keep liveness local to the process.
- Traffic drops when one premium feature breaks: an optional feature check is gating readiness. Report it as degraded instead.
- Probes time out under load: dependency calls run inside the probe request. Move them to a background refresh with a cached result.
- Dashboards show healthy while customers get errors: a required check is missing, or degradation is reported only in a body that nothing reads. Add the missing check and an alert on the degraded metric.
Sources
- Kubernetes documentation, “Configure Liveness, Readiness and Startup Probes,” for probe roles, startup behavior, and the warning that incorrect liveness probes can cause cascading failures.
- Express.js documentation, “Health Checks and Graceful Shutdown,” for the load-balancer purpose of health checks and the liveness and readiness distinction.
- Node.js Reference Architecture (Nodeshift), “Health Checks,” for minimal endpoint examples and the guidance on restarting applications when a database is down.
- NestJS documentation, “Health checks,” for Terminus indicators and degraded status behavior.
- Lightship project documentation, for a library that provides Kubernetes-style probes and graceful shutdown.
These sources define probe mechanics. They do not decide which credential or tier conditions should count as degraded for a particular API, so those rules come from your own service contract.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
