Ceph HEALTH_WARN and HEALTH_ERR checks explained

What Ceph HEALTH_WARN and HEALTH_ERR checks tell you before users notice

When a Ceph cluster reports HEALTH_WARN or HEALTH_ERR, the first decision is whether to act now or schedule the work. HEALTH_WARN means the cluster has detected a condition that deserves attention but is not, on its own, a statement that data is unavailable. HEALTH_ERR means the cluster considers a condition serious enough that normal operation is impaired. Neither level tells you how fast your own response must be, so read the overall status first, then run ceph health detail to see each individual check, the daemons or placement groups it names, and the message the cluster attaches to it. Each check is raised when its condition is detected and cleared automatically once the condition resolves, so a warning that persists after you believe the fault is fixed usually means something else is still wrong.

Severity and urgency are different things. A check at HEALTH_ERR may be a stale cosmetic issue, while a single HEALTH_WARN about a device nearing its failure threshold may need same-day attention because the affected OSD is the only copy of degraded data. Before you act, ask three questions: does the check mean clients are blocked or data is at risk now, is the condition getting worse over time, and does it reduce the redundancy you rely on for your failure domains. Those answers decide the order of work. Because health codes and their thresholds can change between releases, confirm the meaning of each code in the release notes for your running version. The active releases are Tentacle and Squid, and the release index is the place to check which version your cluster runs and how long it is supported.

Muting a warning is a legitimate tool, but it should be recorded and time-limited. Use ceph health mute with a duration and a reason only after you have confirmed the underlying condition is expected, such as a planned maintenance window or a known capacity gap with a dated expansion. A muted check that is never reviewed becomes a hidden risk, so route health output into your monitoring and set an owner for each mute. For alerting and historical context, the Ceph releases page is the starting point for confirming which releases receive backports, and your own runbook should record which codes page the on-call team and which can wait for the next working day.

How HEALTH_OK, HEALTH_WARN and HEALTH_ERR differ in practice

HEALTH_OK means the monitors see no active health checks. All placement groups are expected to be active and clean, every OSD the cluster expects to be up is up and in, and no daemons are reporting problems. Client I/O runs normally and no recovery or backfill traffic should be competing with it. HEALTH_OK does not guarantee that the hardware is healthy in every way, because a failing drive can still be serving data until it fails outright.

Client I/O: Reads and writes are served at normal priority with no health-driven throttling.
Data safety: Each object has its full set of replicas or erasure-coded chunks in place, so a single failure should not cause data loss.
Response time: No immediate action is needed, but the state should be checked regularly through your monitoring rather than only when someone looks at the console.
Hidden risk: Drive wear, SMART counters and slowly rising latency can build while the state still reads OK.
Check: Confirm that ceph health detail returns no entries and that your alerting fires on a transition away from OK, not only on ERR.

Which common health codes need action now and which can wait

This table groups the common Ceph health codes by family and sets out what each one means, whether it needs action now or can wait, and the first command to run. Confirm each code name against the health checks reference for your running release before you write alerts or runbooks around it.

Health code	What it means	Urgency	First command to inspect
OSD_DOWN	One or more OSD daemons are marked down, so their placement groups have fewer copies available.	Act now if the OSD is in a host you expect to be up, or if several OSDs share a failure domain. Wait only for a planned maintenance window.	ceph health detail, then ceph osd tree
OSD_FULL, OSD_NEARFULL	An OSD has crossed the full or nearfull ratio. Full OSDs stop accepting writes, while nearfull is an early warning.	OSD_FULL: act now, because client writes can stop. OSD_NEARFULL: plan capacity work soon, before it becomes full.	ceph osd df, then ceph osd dump \| grep ratio
OSD_SCRUB_ERRORS	Scrubbing found objects whose replicas or checksums disagree. The count is reported across the cluster.	Act now. Identify the affected placement group and check the underlying drive before any repair.	rados list-inconsistent-pg <pool>
PG_DEGRADED	Some objects have fewer copies than the pool requires. Recovery or backfill may be running or waiting.	Act soon if the number is not falling. Wait if recovery is progressing and the cluster has enough headroom.	ceph pg stat, then ceph -s
PG_DAMAGED	Placement groups hold inconsistent or unreadable data that scrubbing or repair has flagged.	Act now. Find the affected objects and confirm the drive state before running a repair.	ceph pg dump_stuck, then ceph health detail
PG_AVAILABILITY	Placement groups cannot serve I/O because too few replicas or shards are available.	Act now. Client requests to those placement groups are blocked or failing.	ceph pg dump_stuck inactive
PG_NOT_DEEP_SCRUBBED	Placement groups have not had a deep scrub within the configured interval.	Usually wait, but schedule it. Check that scrubbing is not being held back by recovery or client load.	ceph pg dump pgs_brief \| grep -i scrub
MON_DOWN	One or more monitors are out of quorum. Losing quorum stops cluster map changes.	Act now if quorum is at risk. A single monitor down with quorum intact still needs prompt repair, because another failure could lose quorum.	ceph quorum_status, then ceph mon stat
MON_CLOCK_SKEW	Clock offset between monitors exceeds the allowed threshold.	Act soon. Correct host time synchronization before quorum or election problems appear. See the clock skew page for chrony setup.	ceph health detail, then chronyc tracking on each monitor host
MON_DISK_LOW	The filesystem holding a monitor's store has less free space than the warning threshold.	Act soon. Monitors cannot compact their stores on a full disk, so resolve it before free space runs out.	df -h on the monitor data path
BLUESTORE_SPILLOVER	BlueFS metadata has spilled from a fast DB device onto slower storage, which slows OSD operations.	Wait for a planned fix, unless latency is already high on those OSDs. Plan a DB device expansion or migration. See the spillover page for detail.	ceph health detail, then ceph daemon osd.<id> perf dump bluefs
BLUESTORE_NO_COMPRESSION style warnings	Compression is not active where you expected it, or the warning reflects a configuration mismatch on a BlueStore OSD.	Usually wait. Confirm whether the setting matters for your pools before changing it, and confirm the exact code name for your release.	ceph config get osd bluestore_compression_mode

How Ceph raises and clears health checks

The monitors (MON daemons) collect health findings reported by OSDs, placement groups, other monitors and managers, then combine them into one cluster health status. Each finding is a named health check with its own code, such as OSD_DOWN or PG_DEGRADED, and a severity of HEALTH_WARN or HEALTH_ERR. The top-level status is a summary, so the cluster health summary is the signal alerting should watch, with the individual check codes used for routing and triage. Checks clear automatically once the underlying condition is resolved, and the status should return to HEALTH_OK without manual action. Confirm in the documentation for your release which checks it raises, their default severity and how each one clears, before you write alert rules that depend on specific codes.

A check caused by one failing drive is usually scoped to a single OSD, plus placement group checks for the PGs that held copies on that device. Because the cluster still has redundancy, data remains available, and the response is a controlled replacement with recovery to watch. Cluster-wide conditions are different in kind. Loss of monitor quorum means the cluster cannot commit map changes, so it needs immediate attention whatever the number of failed drives. Capacity checks such as nearfull or full apply to pools or the whole cluster, and the fix is to add or free capacity, not to replace hardware. A useful first question is how many hosts, OSDs and monitors appear in the detail output. If one drive keeps reappearing across checks or hosts, treat it as a symptom of a shared cause, such as a network or host fault.

Triage a health warning in the order that protects data

This sequence captures the cluster state before anything changes, confirms whether clients are affected, and checks the foundations (quorum, time and placement) that every other fix depends on. It ends with a deliberate decision to act, schedule work or mute a warning for a stated period.

Capture cluster state before changing anything
The on-call engineer runs ceph status and ceph health detail from a host with admin credentials and saves both outputs with a timestamp before touching any daemon. Run ceph health detail in the same window so the per-check messages match the summary. Keep a copy of the cluster version from ceph versions, since behavior of some health checks depends on the release. This step is done when the raw output is stored in the incident record and the engineer can name the health codes in the summary line.
Check whether client I/O is blocked
Determine first whether applications are waiting on the cluster. Look for slow or blocked request messages in the health output and check whether any PGs are inactive, peering or incomplete, because those states stop I/O to the affected objects even when the overall status reads HEALTH_WARN. Compare the time the warning started with the time users reported errors, and ask the platform owners of RBD, CephFS and RGW consumers whether they see timeouts. This step is done when you can state either that client I/O is unaffected or which pools and clients are blocked.
Confirm monitor quorum and time sync
Check that the monitors are in quorum with ceph quorum_status or the monitor section of ceph status, and confirm that every monitor host is reporting the expected membership. Next, check clock health on the monitor hosts, since clock skew produces its own health warning and can cause monitors to misbehave. If quorum is lost, stop further changes and escalate, because OSD and PG decisions depend on a working monitor majority. This step is done when quorum is confirmed with the member list recorded, and time sync is either confirmed healthy or flagged for a separate fix.
Review OSD and PG states
Use ceph osd tree and ceph osd stat to see which OSDs are down, out or full, and group them by host and failure domain. Then use ceph pg stat and ceph pg dump_stuck to see whether PGs are degraded, undersized, backfilling or inconsistent. Note whether the affected OSDs share a host, a rack or a drive model, because a shared cause points to a host or batch problem rather than a single failed drive. This step is done when you have a written list of affected OSDs and PG states that matches the health detail output.
Identify the health code and its urgency
Match each code in the health detail output to its documented meaning in the Ceph health checks reference for your release, and mark it as data-risk, service-impacting or housekeeping. Treat any code that involves data availability, inconsistent objects or full devices as time-sensitive. Treat codes about deprecated settings or old versions as work to schedule. Record which codes you cannot explain yet, because those need a closer read before any action. This step is done when every active code has a category and an owner.
Decide between action, scheduled work and a mute
Choose one of three outcomes for each code. Act now when clients are blocked, data is at risk or a device is close to full. Schedule work when the code is real but the cluster is serving I/O safely, and create a ticket with the saved output attached. Mute only when the warning is understood, a fix is planned, and the mute has an expiry; check the mute command syntax in the health checks reference for your release before running it. This step is done when each code has a recorded decision and, for any mute, a named owner and an expiry time.
Save the record for the support case
Before closing the incident, store the captured outputs, the timeline of changes, every command run and its result, and the reasoning behind each decision in one place. Include the Ceph release, the cephadm-managed daemon versions and any muted checks with their expiry. If a vendor or community support case will follow, attach the logs from the affected daemons and note which hosts they came from. This step is done when someone who was not on the call could reconstruct what happened and why each decision was made.

When muting a Ceph health warning is safe and when it hides risk

A mute silences a health code without fixing its cause, so it is only safe when the reason is known, bounded and reviewed. The cards below separate mutes that fit a plan from mutes that quietly hide a growing problem in a Ceph cluster.

Time-boxed mutes with an expiry

A mute with an expiry is the safest form because it returns the warning to the dashboard on its own. Use it for a known, bounded condition such as a single drive awaiting replacement or a recovery that will finish on a known schedule. Before setting the expiry, confirm that the warning will still be visible when the mute ends, and check the mute syntax for your release, since the health mute command and its options vary between versions. Expect that a mute set without an expiry will be forgotten.

Mutes that mask capacity growth

The most dangerous mute is one placed on a nearfull or full warning while raw usage keeps climbing. Each new write brings the cluster closer to the point where client I/O stops, and the mute removes the only signal that would prompt action. Before muting any capacity code, compare current utilization against the trend over recent weeks and confirm that someone has a dated plan for adding capacity or deleting data.

Muting during planned maintenance

Warnings such as degraded or remapped placement groups are expected while you drain a host, replace a failed component or run a planned upgrade. A short mute for the maintenance window keeps routine alerts from burying real events. Confirm the mute covers only the codes you expect, and remove it as soon as the window closes. Pair the mute with a note in the change record so that a warning that persists after the window is treated as new.

Recording the reason and owner

Every mute should carry a written reason, the health code it silences, the name of the person accountable for it, and a link to the ticket or change record. Without these fields, a mute becomes an unexplained exception that nobody can judge during an incident. Ask your team to review open mutes at each on-call handover, and confirm that your ticketing process captures who set each one and when.

Why permanent mutes are never safe

A permanent mute removes a health code from the cluster's normal view for as long as it exists, so a later, unrelated failure with the same code can go unnoticed. Health codes are designed to be read as current state, and a permanent silence turns them into stale history. If a condition truly cannot be fixed, record it as an accepted risk with a review date, and fix the monitoring so that the condition is tracked outside the health output.

Questions teams ask before handling Ceph health alerts

Can a Ceph HEALTH_WARN wait until business hours?

Often yes, but only after someone has confirmed what the warning is. A HEALTH_WARN usually means the cluster is still serving I/O while something needs attention, such as a daemon running late on a version, a pool nearing its quota, or a scrub that has fallen behind. Warnings about failed or unreachable monitors, placement groups that are inactive or undersized with no recovery progressing, or OSDs approaching full ratios deserve prompt action. Read the detail with ceph health detail before deciding. A warning that is stable and understood can usually be scheduled, while one that changes between checks should be treated as live. Write down who owns the decision so the on-call engineer does not have to guess overnight.

How much time and skill does a Ceph health investigation take?

The effort depends on how many health codes are active, how much data is affected, and how familiar the team is with the cluster's layout. A single cosmetic warning on a healthy cluster can be closed in a short session. A cluster with degraded placement groups, slow requests and a failing drive may need hours of correlated work across OSD logs, host metrics, network counters and recovery progress. The skill needed spans Ceph internals (monitors, OSDs, placement groups, BlueStore), the host operating system and the network. Ask any partner to describe its triage method and what evidence it collects before it quotes, because the scope should follow the number and severity of active checks rather than a flat assumption.

What access, logs and change windows does a health investigation need?

Investigators need read access to cluster status, OSD and monitor logs, and host-level metrics, and they need the cephadm or orchestrator view of which daemons run where. Without historical logs and monitoring data, root cause work becomes guesswork. Plan for these inputs before an incident:

Command output from ceph status, ceph health detail and ceph osd tree, captured over time
Daemon logs from every monitor, manager and OSD involved
Drive SMART data, network error counters and clock sync status for affected hosts
An approved change window for any action that moves data, restarts daemons or changes flags

Confirm with your team which of these exist and who can approve changes in production, since the answer shapes how quickly any fix can proceed.

Can an in-house team handle Ceph health alerts without outside help?

Yes, many teams do, provided they have at least one engineer who understands placement groups, CRUSH placement and the recovery model, and who has rehearsed the common procedures on a non-production cluster. Gaps usually appear in recurring warnings that point to hardware, network or sizing problems, and in incidents where several codes appear at once. Assess your own team honestly: check whether alerts route to people who can act on them, whether runbooks exist for full and nearfull OSDs, scrub errors and slow requests, and whether someone can explain why a mute is safe. If those answers are weak, a short external review can close the gap while your staff build the skills.

When should an organization bring in a Ceph partner for health issues?

Consider a partner when an incident involves data at risk, when the same warning returns after repeated fixes, when the team lacks someone with deep Ceph experience, or when a regulated environment requires documented, repeatable evidence of the response. A partner is also useful before a planned upgrade or expansion, when the health history will show whether the cluster is ready. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted open-source platforms inside your own infrastructure, so any engagement would run in your environment. Agree the scope in writing before work starts, and ask what remains with your team after the review.

What drives the cost of a Ceph health review?

The main cost drivers are the number and severity of active health codes, the size of the cluster and the amount of affected data, how much historical data is available, the number of hosts that need inspection, and whether the work is a one-time investigation or an ongoing retainer. Ongoing support, upgrades and continuous testing are available as retainers, while most engagements are fixed-scope with deliverables and timelines agreed in writing. DeployOpen does not publish a price list, so a quote follows from the written scope. When requesting one, ask what is included in triage, what evidence is collected, what happens if new codes appear mid-work, and what deliverables you receive.

Is it safe to mute a Ceph health warning?

Muting is safe only when you understand the underlying condition and have a documented reason to suppress the alert for a defined period. Ceph allows health checks to be muted with a time limit, which prevents a temporary silence from becoming permanent. Before muting, confirm the check's cause in ceph health detail, record who approved it, and set an expiry that matches your review cycle. Never mute a check you cannot explain, and do not use a mute to hide a warning that affects data durability. Review active mutes regularly, since a muted warning that escalates will not reach your alerting pipeline unless you watch for it separately.

Security and operational risks behind health warnings

A health warning is only useful if the cluster state behind it can be trusted and the people acting on it are accountable. The cards below cover the decisions that turn a routine check into an incident, from clock and quorum problems to muted alerts and unrecorded changes.

Monitor quorum and clock skew

Monitors vote on cluster maps, so a monitor that drifts out of quorum or sees skewed time can change what the cluster believes about OSD and PG state. Check ceph quorum_status and the clock skew warning before acting on OSD or PG codes, because a health result from a split or unsynchronized monitor set may describe a state that does not exist. Confirm that every monitor host runs a time service with a known upstream source.

Admin access behind mute and repair

Commands such as ceph health mute, ceph pg repair and OSD removal change cluster behavior or hide evidence, yet they are often run with the full admin keyring. Restrict which operators hold admin capabilities, use named accounts, and record who ran each command. Ask your team which commands require a second reviewer and whether cephadm host access is limited to the same group.

Changes made under pressure

During an incident, staff raise ratios, restart daemons, or delete data to clear a warning, and the reasoning is lost by the next shift. Keep a change log for every override, mute and repair, with the health code, the command, the expected effect and the rollback step. Review the log after each incident so temporary settings do not stay in place as permanent configuration.

Alert routing that exposes cluster details

Alertmanager receivers and webhooks often carry full health detail, including pool names, hostnames, OSD IDs and capacity figures, to chat tools or ticket systems with broad membership. Review which channels receive raw health payloads, restrict external integrations, and confirm that dashboard access follows the same authentication model as your other administrative tools.

Keeping health output in a log store

Health output that exists only on the terminal disappears when the session closes, and cluster history is needed to explain recurring warnings. Ship daemon logs and periodic health snapshots to a central store with retention that matches your incident review cycle. Confirm who can read those logs, since they can reveal topology and client activity.

What an in-house team should build before the next warning

The most useful thing a team can build before the next warning is a health summary feed that a person reads before the alert does. Run ceph health detail on a schedule, store the output with a timestamp, and send any change in health code to the team channel. The point is to see a new HEALTH_WARN code the moment it appears, not when a client reports slow writes. Confirm how your monitoring stack exposes these codes, since cephadm can deploy Prometheus and Alertmanager, and decide whether the feed comes from there, from a cron job, or from both. The setup of that stack is covered on the monitoring page, so this section only sets the requirement.

Next, write a runbook for each code family rather than one generic page. Group codes by the component they describe: OSD, PG, monitor, and BlueStore. Each runbook should name the first command to run, the owner who acts on it, the conditions that make it urgent, and the point at which the team escalates to a partner or the vendor. Keep the runbooks in version control next to your cluster configuration so they match the release you run. Several codes have dedicated pages in this group, including full OSDs, slow ops, scrub errors, monitor clock skew and BlueStore spillover, so link to those procedures from the runbook instead of copying them.

A documented mute policy is the third element. A muted warning stays hidden from the summary until it expires, so every mute needs a named owner, a reason, and an expiry date, and the policy should say who may approve one. Record the mute in your change system and review open mutes at each shift or weekly review. Finally, test the triage steps before you need them. Run a planned exercise on a non-production cluster, inject a known condition, and time how long the on-call engineer takes to classify it and reach the right runbook. Ask your team, or any partner you engage, to show the exact mute and unmute commands on your release, because syntax and behavior should be confirmed against the documentation for the version you run.

Set up health monitoring and triage runbooks

This sequence turns Ceph's health output into an alerting and response process your team can run without guesswork. It confirms the release you run, routes health changes to the people on call, documents one runbook per code family, sets an approval path for muting, and proves the whole chain with a controlled fault outside production.

Confirm the running Ceph release
Someone on the platform team runs ceph versions and ceph orch ps to record the release every daemon is running, then checks that the cluster is on a release that is still actively maintained. Ceph's release index lists Tentacle (20.2.x) and Squid (19.2.x) as the actively maintained releases, with their estimated end-of-life dates, so confirm which series you run before you write runbooks against its health codes. Output: a dated record of the release per daemon type, stored with the runbook. Done when every daemon reports the same expected series and any mixed versions are explained.
Capture the health summary baseline
Run ceph health detail on a healthy cluster and save the output, along with ceph status and the list of health codes the cluster can raise. This baseline shows what a normal idle cluster looks like, including any warnings that already exist and should be fixed or documented as accepted. Output: a baseline file that the on-call team can compare against during an incident. Done when the team agrees which existing warnings are known and which need an owner.
Route health changes to alerting
Connect the cluster's health state to your alerting path, typically through the monitoring stack cephadm deploys or your existing Prometheus and Alertmanager. Alert on transitions to HEALTH_WARN and HEALTH_ERR, and on individual health codes where your tooling exposes them, so a page carries the code name and not only a color. Set routing so HEALTH_ERR reaches the on-call engineer and HEALTH_WARN reaches a ticket queue. Confirm the exact metric names and alert rule syntax in your installed release before you rely on them. Done when a test notification arrives at the right destination with the health code visible.
Write one runbook per code family
Group health codes into families such as OSD, PG, monitor and BlueStore, and write one runbook for each family. Each runbook lists the codes it covers, the questions to answer first (which daemons, which pools, how much data is affected), the commands that show the detail, the conditions that need action now, and the conditions that can wait for a planned change. Link each runbook to the sibling procedures for full, slow request, scrub error and drive replacement work where they apply. Output: a version-controlled runbook set. Done when an engineer who did not write the runbook can name the first command and the escalation point for each family.
Define the mute approval path
Decide who may mute a health code, for how long, and what record must exist when they do. Ceph allows health checks to be muted, and a muted code can hide a condition that is getting worse, so the approval path should require a named owner, a reason, a ticket reference and an expiry or review point. Confirm the mute and unmute command behavior in your release's documentation before you publish the procedure. Output: a written approval path and a log location for mutes. Done when the team can show who approved the last mute and when it will be reviewed.
Rehearse with a non-production fault
On a non-production cluster that mirrors your production layout as closely as practical, stop one OSD or take one monitor offline and watch the health output change. Follow the matching runbook from the alert to the resolution, time each decision in the team's own notes, and record any step that was unclear. Repeat with a second family, such as a PG or BlueStore warning, if the cluster allows. Output: a rehearsal record listing gaps and runbook edits. Done when the on-call engineer completes the path without help from the author and the alert routing delivered as expected.
Review runbooks after each change
Assign an owner to review the runbooks and the alert rules after each Ceph upgrade, hardware change or new health code that appears in the release notes. Compare the baseline from the earlier step with current output to catch changed codes or new warnings. Output: a dated review entry and updated runbooks where needed. Done when the review record names the release, the changes checked and the next review trigger.

What a DeployOpen health review covers

A DeployOpen health review examines how your Ceph cluster reports its own condition and whether your team would act on those reports in time. The review is scoped in writing before work starts, so the reader knows which hosts, daemons, health codes and alert channels are in and out. The starting point is usually the output of ceph health detail, the active alerts in whatever monitoring stack you run, and the set of muted checks. Muted warnings deserve close attention, because a check silenced months ago for a planned maintenance window often remains silent long after the reason has gone. Agree in advance whether the review covers only the cluster as deployed or also the cephadm service specifications that shape it.

The review typically covers three areas. First, the health check inventory: which codes have fired in the past, which are currently muted and with what expiry, and which conditions your cluster can reach but nobody has seen yet, such as nearfull ratios on OSDs or monitor quorum loss. Second, the runbooks: for each code that matters to you, whether a documented first response exists, who owns it, and which commands the on-call engineer runs. Third, alerting: whether Prometheus rules and Alertmanager routes, or an existing monitoring platform, actually deliver HEALTH_WARN and HEALTH_ERR transitions to someone who can act, and whether alerts fire during recovery when the cluster is expected to look unhealthy. Each area can be reviewed at a different depth, so the scope document should name the depth for each.

Deliverables are agreed up front and usually take the form of a written findings report, a prioritized list of changes, and revised runbooks or alert rules, depending on what was scoped. Ask the vendor to state which artifacts you will receive, who approves changes to production alerting, and what happens if the review finds a live HEALTH_ERR condition that needs immediate work. Cost follows the scope. The main drivers are the number of clusters and sites, how many health codes and runbooks are in play, whether your monitoring is cephadm-managed or external, and how much access to logs and hosts the work needs. Ask for a quote that separates a one-time review from any ongoing retainer for follow-up, and confirm the timeline and access requirements in writing before the review begins.

How DeployOpen works on this

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including Ceph clusters in your data centers or air-gapped networks. For HEALTH_WARN and HEALTH_ERR work, we start from your cluster's actual health output, decide which codes need action now, and agree the remediation steps in writing before anything changes.

How we scope

We review your current health output, alert history and cluster layout before agreeing what the work covers.
Each health code in scope is listed with its owner, the evidence we will collect and the action expected.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Quotes follow from the written scope, so ask for each health area and each cluster to be itemized.

How we build

We confirm the cephadm release line and version in use before recommending any change to a health check or threshold.
Muting or tuning rules are drafted with a written expiry, an owner and a record of the reason for the change.
Alerting on health codes is tested against a staging or maintenance window so that noisy or missing alerts are caught early.
Remediation steps are rehearsed on a non-production cluster where your environment allows it.

How we hand over

You receive a runbook that maps each health code to its first checks, the commands used and the escalation path.
Triage decision notes explain why a warning is urgent, can wait or should be muted, so your team can repeat the reasoning.
Knowledge transfer sessions walk your operators through the runbook using your own cluster output.
Documentation stays in your infrastructure and is kept under version control on your side.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
Retainer reviews can re-check muted warnings, expired mutes and alert rules after each Ceph upgrade.
Ask us to confirm the support hours, response process and included upgrade work before you sign.
Health code guidance is revisited when your release line changes, so the runbook stays accurate for your version.

What Ceph HEALTH_WARN and HEALTH_ERR checks tell you before users notice

How HEALTH_OK, HEALTH_WARN and HEALTH_ERR differ in practice

Which common health codes need action now and which can wait

How Ceph raises and clears health checks

Triage a health warning in the order that protects data

Capture cluster state before changing anything

Check whether client I/O is blocked

Confirm monitor quorum and time sync

Review OSD and PG states

Identify the health code and its urgency

Decide between action, scheduled work and a mute

Save the record for the support case