fix(status): handle Serverless Elasticsearch in elastic status

[MattDevy]

Problem

elastic status reports Elasticsearch as down on Serverless projects, even when the project is healthy:

Context: cli-demo

  Elasticsearch  https://cli-demo-f41c2c.es.us-east-1.aws.elastic.cloud  ✗  request failed (410)
  Kibana         https://cli-demo-f41c2c.kb.us-east-1.aws.elastic.cloud  ✓  available (9.5.0)

Root cause

The Elasticsearch probe calls GET /_cluster/health (src/status/checks.ts). Serverless removes cluster-level APIs and answers that endpoint with 410 Gone, which the generic HTTP classifier turned into request failed (410). Kibana's /api/status exists on Serverless, so it already showed ✓.

Confirmed against a live Serverless project:

Endpoint	Status
GET /	200 (returns version.number, build_flavor: serverless)
GET /_cluster/health	410
GET /_security/_authenticate	200

Fix

• pingService now surfaces the HTTP status code on failure.
• checkElasticsearch keeps the single /_cluster/health request for stateful clusters. On a 410 specifically, it falls back to GET / (served on Serverless) and reads version.number.
• EsCheckOk becomes a discriminated union: EsCheckStateful { flavor, status, nodes } | EsCheckServerless { flavor, version }.
• The formatter renders Serverless as serverless (<version>); stateful output is unchanged.

Only a 410 triggers the fallback. Other failures (401, 503, network) are still reported as failures, and stateful clusters are completely unaffected.

Result

Context: cli-demo

  Elasticsearch  https://cli-demo-f41c2c.es.us-east-1.aws.elastic.cloud  ✓  serverless (9.5.0)
  Kibana         https://cli-demo-f41c2c.kb.us-east-1.aws.elastic.cloud  ✓  available (9.5.0)

Exit code is now 0.

Test plan

• tsc -b clean
• All 45 status tests pass (test/status/*.test.ts)
• New tests: 410 → serverless fallback success, missing version.number → unexpected response, root failure propagation (401), serverless rendering
• Verified live against a Serverless project (output above)
• Stateful path / output unchanged (existing tests green)

[github-actions]

✅MegaLinter analysis: Success

Descriptor	Linter	Files	Fixed	Errors	Warnings	Elapsed time
✅ COPYPASTE	jscpd	yes		no	no	0.64s
✅ REPOSITORY	gitleaks	yes		no	no	57.7s
✅ REPOSITORY	git_diff	yes		no	no	0.13s
✅ REPOSITORY	secretlint	yes		no	no	10.89s
✅ REPOSITORY	trivy	yes		no	no	24.54s
✅ TYPESCRIPT	eslint	4		0	0	3.59s

Notices

📣 MegaLinter 9.5.0 is out! Discover the new features and security recommendations in the release announcement. (Skip this info by defining SECURITY_SUGGESTIONS: false)

See detailed reports in MegaLinter artifacts
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff

MegaLinter is graciously provided by OX Security
Show us your support by starring ⭐ the repository

[JoshMock]

My only suggestion: if we have any hints that a cluster might be serverless (its hostname, perhaps, or if the commandProfile is set to serverless), we should run the serverless check first to reduce the chances of sending a request that's doomed to fail.

[eedugon]

@JoshMock I reproduced this today with CLI 0.4.0 against a live Serverless project using an Elastic Cloud API key with Elasticsearch access. elastic status still reports:

Elasticsearch  <serverless-endpoint>  ✗  request failed (410)

At the same time, elastic --json es info succeeds and returns build_flavor: serverless, confirming that the endpoint and authentication are valid.

This is especially noticeable during onboarding: a user can configure Serverless correctly and the first status check tells them the request failed. It gives a poor first impression and strongly suggests that their configuration or credentials are broken. Since the fix is already approved, could we get it merged and included in the next release?

[cla-checker-service]

❌ Author of the following commits did not sign a Contributor Agreement:
8fe7e68

Please, read and sign the above mentioned agreement if you want to contribute to this project

[JoshMock]

CLA check is failing because Matt authored this PR but no longer works at Elastic. 💔 I'm just finishing his work and merging.