Linked project unavailable

When a linked project in the datafeed's scope is skipped during a search cycle, Elasticsearch fails the entire extraction cycle instead of continuing on the remaining projects. Partial cross-project results could produce spurious anomalies, so the cycle produces no data, the error is audited, and the datafeed retries on its next scheduled cycle. You see repeated extraction errors in Job messages and gaps in results for the affected time buckets until every project in scope is reachable again or you narrow project_routing. A hard cluster failure (status FAILED, not SKIPPED) surfaces through the ordinary search-failure path with different Job messages text.

Where to look

• anomaly detection job job messages in Kibana: Open Machine Learning → Anomaly Detection, select the job, and review the Job messages tab for audit entries and warnings about linked projects, credentials, or scope changes. On the Datafeed tab, View datafeed counts opens the datafeed chart flyout for extraction timing.

  The same entries are stored in .ml-notifications-*.

• GET _ml/datafeeds/{datafeed_id}: Shows the effective project_routing value and, when an internal cloud credential exists, authorization.cloud_api_key.id.

• GET _ml/datafeeds/{datafeed_id}/_stats: While the datafeed runs, shows remote_cluster_stats with total_clusters, available_clusters, skipped_clusters, availability_ratio, stabilized_cluster_aliases, and per_cluster_consecutive_skips. The object is absent until the first search cycle establishes a baseline.

• .ml-annotations-*: Scope-change annotations for the job. The annotation event field carries search_scope_changed (not the separate type field).

• GET /_project/tags: Lists linked projects and their tags so you can compare them with a routing expression.

• Elastic Cloud console: Review linked projects in Link and manage projects.

During active extraction problems, Job messages are authoritative. remote_cluster_stats from get datafeed stats reflects the last completed cycle.

Error messages

Skipped or failed linked projects surface in the anomaly detection job's Job messages tab (or .ml-notifications-*). The outer audit entry wraps the skip summary as its cause:

Datafeed is encountering errors extracting data: [1] remote clusters out of [3] were skipped when performing datafeed search
		

The bracketed skip and total counts vary with how many linked projects are in scope. The wrapped text is the message thrown when any linked project is skipped during the search.

Read the per-project statistics

Inspect remote_cluster_stats via get datafeed stats.

During an active skip outage, skipped_clusters can remain 0 while skip errors repeat in Job messages because extraction aborts before stats are updated.

After cycles complete successfully, compare per_cluster_consecutive_skips and availability_ratio with project_routing from GET _ml/datafeeds/{datafeed_id} and linked projects from GET /_project/tags or the Cloud console.

Example excerpt (field names and structure match the stats API, values vary):

"remote_cluster_stats": {
  "total_clusters": 3,
  "available_clusters": 3,
  "skipped_clusters": 0,
  "availability_ratio": 1.0,
  "stabilized_cluster_aliases": ["origin", "production", "staging"],
  "per_cluster_consecutive_skips": {}
}
		

Distinguish configuration from an outage

For routing or stale alias problems, see Project scope problems.

Rule out an authorization failure

An internal cloud credential problem can also stop cross-project searches. The distinguishing signal is a credential-specific message in Job messages, for example an authentication failure on the internal cloud API key or a forbidden response while using that key, rather than the skip summary above. See Cloud credential problems.

Restore the project link

If the linked project was removed or never linked, re-establish it in Link and manage projects, then wait for the next extraction cycle or restart the datafeed.

Remove the unavailable project from scope

When a project stays unreachable and you need the datafeed to keep producing results from the remaining scope, narrow project_routing to an _alias: expression that excludes the unavailable project:

Stop the datafeed before updating it. If the datafeed is still running, the update fails with:

Cannot update datafeed [my-datafeed] while its status is started
		

The bracketed datafeed id and status vary with your configuration.

When a project_routing update changes the effective search scope, Elasticsearch retains the job's current model snapshot as a rollback point before applying the change. By default, that rollback gate requires the anomaly detection job to be closed. If the job is still open, the update fails with:

Cannot update project_routing for datafeed [my-datafeed] while job [my-job] is opened. Close the job so a rollback model snapshot can be retained.
		

The bracketed datafeed id, job id, and job state vary with your configuration.

The rollback gate also requires an existing model snapshot. If the job has never produced one, the update fails with:

Cannot update project_routing for datafeed [my-datafeed] because job [my-job] has no model snapshot to use as a rollback point. Open the job, ingest data, then close it before changing scope.
		

A job that has never run has no snapshot. Open it, let it process data, then close it before changing project scope.

Elasticsearch records the retained rollback snapshot in the job's Job messages (or .ml-notifications-*), for example:

Rollback model snapshot [1720000000] retained before project_routing scope change: Automatic rollback snapshot retained before project_routing scope change [] -> [_alias:prod-*]
		

When the datafeed already had a stored routing value, the bracketed pair shows the old and new expressions instead of an empty left side:

Rollback model snapshot [1720000000] retained before project_routing scope change: Automatic rollback snapshot retained before project_routing scope change [_alias:_origin] -> [_alias:prod-*]
		

You can revert to that snapshot if detection quality degrades after a scope change.

Exception: assigning _alias:_origin for the first time to a datafeed that had no project_routing preserves the existing local-only scope. That update bypasses the rollback gate entirely. Neither the closed-job check nor the snapshot requirement applies.

				POST _ml/datafeeds/{datafeed_id}/_update
					{
  "project_routing": "_alias:production-*"
}
		

Use an expression that matches only the linked projects you still need. Changing scope can affect the model. See Changing project scope.

Wait out a transient outage

When the underlying link or platform issue clears, the datafeed recovers on the next successful cycle without configuration changes. Job messages might show:

Datafeed has recovered data extraction and analysis
		

After a long period with no ingested data, you might also see:

Datafeed has started retrieving data again
		

Consider the model impact

Each failed extraction cycle leaves a gap in the time series the anomaly detection job analyzes. If a project stays out of scope for an extended period (whether because of outages or because you narrowed routing), the model adapts to the changed data distribution. See Changing project scope for rollback options.

Verify

Job messages should stop reporting new extraction errors for the skip cause. After at least one successful completed cycle, remote_cluster_stats should show skipped_clusters at 0 and no non-zero entries in per_cluster_consecutive_skips.

When to contact support

If many unrelated datafeeds still skip the same linked project after you confirm the project link and project_routing are correct, contact Elastic support with the project id, datafeed id, and the extraction error message text.