Generated banner for Elasticsearch Reindex
Generated logo for Elasticsearch Reindex

Elasticsearch Reindex

ElasticOfficialCreated by elastic

  • Skill
  • Tool integration
  • Software development
  • Apache-2.0
  • No issues found

From the author

Guide Elasticsearch reindex for performance: local and remote, slicing, throttling, task API. Use when copying or migrating indices, changing mappings, or transforming during reindex.
— the description by elastic

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured workflow for copying or migrating data between Elasticsearch indices. It covers critical aspects of the reindex process, including environment verification, destination preparation, performance tuning, and task management. It emphasizes best practices such as using asynchronous task execution for large jobs, applying filters to limit data scope, and verifying results through document counts. The skill is designed to help users navigate the differences between self-managed, Elastic Cloud Hosted, and Serverless deployment environments.

What it does

  • Guides the preparation of destination indices with correct mappings and settings.
  • Facilitates local and remote cluster data migration.
  • Provides methods for filtering data subsets during the reindex process.
  • Supports performance optimization via slicing, throttling, and batch sizing.
  • Enables asynchronous task tracking and management.
  • Ensures data integrity through post-reindex count verification.

When to use it

  • When you need to change field mappings or analyzers on an existing index.
  • When migrating data between different Elasticsearch clusters.
  • When you need to transform data during the copy process.
  • When you need to copy a specific subset of data based on time ranges or other filters.
  • When consolidating indices or data streams.

Advantages

  • Reduces risk of partial failures by enforcing explicit destination preparation.
  • Improves performance for large datasets using parallel slicing and throttling.
  • Provides clear guidance on deployment-specific constraints.
  • Minimizes downtime by supporting alias swaps and asynchronous background tasks.

Usage examples

“How do I reindex a large index named events into events-v2 while throttling the speed?”
The agent will provide the POST /_reindex command with slices=auto and a specified requests_per_second parameter to manage cluster load.
“I need to migrate only the logs from January 2025 from my metrics index.”
The agent will guide you to create a destination index and use a source query with a range filter on the @timestamp field.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/elastic/elasticsearch-reindex/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip elasticsearch-reindex.zip -d .agents/skills

Documentation by elastic

Elasticsearch Reindex

Copy documents from source indices or data streams to a destination using POST /_reindex. An expert reindex workflow prepares the destination explicitly, chooses local versus remote execution, filters at the source when only a subset is needed, runs long copies asynchronously, tracks the task to completion, and verifies the destination document count before reporting results.

<!-- begin-partial: preamble -->

Environment Configuration

This skill executes Elasticsearch operations through the elastic CLI. If the elastic CLI is not installed, tell the user what it is needed for. Do not guess credentials, call the HTTP API directly, or attempt other workarounds.

This skill references operations in HTTP-shorthand form (e.g., GET /, GET /_cat/indices, GET /{index}/_mapping, GET /{index}/_settings/index.mode, POST /_query). The Operations table at the end of this document maps each shorthand to the equivalent elastic CLI command — always use the CLI rather than calling the HTTP API directly.

<!-- end-partial: preamble -->

Process

  1. Confirm connectivity and deployment type. Call GET /. Read build_flavor and version.number to know whether shard, replica, and cluster-settings APIs are available (Serverless manages shards/replicas internally and blocks most _cluster/* APIs). The decision: continue only when the cluster is reachable. If the call fails, stop — do not guess endpoints or credentials.

  2. Decide local versus remote reindex. Compare where the source and destination live.

    • Same cluster — use local reindex: source.index and dest.index only. Do not add source.remote when both indices are on the cluster you are connected to.

    • Different cluster — use reindex from remote: add source.remote with the remote cluster URL and credentials. Remote reindex does not support slicing; compensate with query-based partitioning (date ranges, term filters) across parallel requests. Confirm the remote host is allowlisted on Self-Managed / ECH (reindex.remote.whitelist in cluster config); Serverless manages allowlisting internally (ECH remotes only, Tech Preview).

    Data needed: source index name(s), destination index name, and whether they share a cluster.

  3. Inspect the source — never guess field names or counts. Call GET /{source}/_mapping to ground field names and types. Call GET /{source}/_count (or GET /_cat/count/{source}?h=count on Self-Managed / ECH) to learn how many documents exist.

    The decision: full copy versus filtered subset.

    • Full copy — omit source.query (match-all behavior).

    • Filtered subset — add source.query with Query DSL. For time ranges, use a range filter on the timestamp field (commonly @timestamp), e.g. "gte": "2025-01-01", "lt": "2025-02-01" for January 2025. Do not run a full-index copy when the user asked for a date range or other filter.

    Data needed: the user's filter criteria and the mapping-confirmed field names.

  4. Prepare the destination index before copying. _reindex does not copy mappings, shard counts, or analyzers. Create the destination with explicit settings and mappings derived from the source mapping via PUT /{dest}.

    • On Self-Managed / ECH: set number_of_replicas: 0 and refresh_interval: "-1" on the destination during the copy for write throughput; restore production values afterward with PUT /{dest}/_settings.

    • On Serverless: omit number_of_shards and number_of_replicas (managed by Elastic); you may set refresh_interval: "-1" during the copy.

    • For data stream destinations: ensure an index template with data_stream: {} exists, create the data stream, and set dest.op_type to "create" (append-only).

    The decision: create/prepare the target rather than relying on auto-creation with dynamic mapping. Wrong or missing mappings cause partial failures or silent type coercion.

    Data needed: destination name, corrected or compatible mappings, and deployment-specific settings constraints.

  5. Build and submit the reindex request. Call POST /_reindex?wait_for_completion=false for any copy that may take more than a few seconds or when the user says the index is large — the response returns a task id immediately instead of blocking.

    Request body essentials:

    • source.index — source index or data stream (correct name, not reversed with dest.index).

    • dest.index — prepared destination from step 4.

    • source.query — include only when step 3 chose a filtered subset.

    • conflicts: "proceed" — when retrying a partially complete reindex.

    • Optional tuning: source.size (batch size), requests_per_second (throttle), slices=auto on local reindex only (parallelize per primary shard — never for remote), scroll (increase keep-alive on slow clusters), max_docs (test runs), script (transform), dest.pipeline (ingest enrichment).

    Example filtered subset (January 2025 only):

    {
      "source": {
        "index": "eval-reindex-src",
        "query": {
          "range": {
            "@timestamp": { "gte": "2025-01-01", "lt": "2025-02-01" }
          }
        }
      },
      "dest": { "index": "eval-reindex-jan" }
    }

    Do not reach for _split, _shrink, or snapshot/restore when the task is a filtered subset copy or a straight document migration — those APIs solve different problems.

  6. Track the task to completion. Store the task id from the reindex response. Poll GET /_tasks/{task_id} until completed is true. Read status.total, status.created, and response.failures. On Self-Managed / ECH you may also list active reindex tasks with GET /_tasks?actions=*reindex&detailed; on Serverless, query by task id only (list/cancel are not available). Adjust throttling mid-flight with POST /_reindex/{task_id}/_rethrottle?requests_per_second=N without canceling.

  7. Verify and report the destination count. Call GET /{dest}/_count (works on all deployment types). On Self-Managed / ECH you may also use GET /_cat/count/{dest}?h=count. Compare source filter expectations to the destination count. Report the exact count from the destination — do not estimate or guess.

    After a successful full copy, restore production settings on the destination with PUT /{dest}/_settings (replicas and refresh interval on Self-Managed / ECH; refresh interval only on Serverless).

Deployment constraints

CapabilitySelf-Managed / ECHServerless
Local reindexFull supportFull support
Reindex from remoteFull supportTech Preview — ECH remotes only
number_of_shards/replicasUser-configurableManaged — omit on index creation
slices=auto (local only)SupportedSupported for local reindex
GET /_cat/count/{index}SupportedNot available — use GET /{index}/_count
GET /_tasks (list/cancel)FullGet by task id only
PUT /_cluster/settingsSupportedBlocked
_split / _shrinkSupportedNot available

Consider alternatives first

  • Runtime fields — fix field-type mismatches or add computed fields without reindexing when stored values need not change.

  • Aliases — redirect queries transparently; combine with reindex for zero-downtime mapping changes.

  • Snapshot and restore (Self-Managed / ECH) — faster whole-index transfer when no transformation is needed.

See the decision tree in references/patterns.md.

Reference material

Examples

"Copy logs-2024 into a new index with a corrected mapping" — create the destination first, then reindex:

POST /_reindex
{ "source": { "index": "logs-2024" }, "dest": { "index": "logs-2024-v2" } }

"Reindex a large index in parallel and throttle it" — slice automatically and cap the request rate:

POST /_reindex?slices=auto&requests_per_second=2000
{ "source": { "index": "events" }, "dest": { "index": "events-v2" } }

"Migrate only recent documents" — filter the source with a query:

POST /_reindex
{
  "source": { "index": "metrics", "query": { "range": { "@timestamp": { "gte": "now-30d" } } } },
  "dest": { "index": "metrics-recent" }
}

Guidelines

  • Confirm deployment type first. Call GET / and read build_flavor; shard, replica, cluster-settings, and task APIs differ between Self-Managed / ECH and Serverless (see Deployment constraints).

  • Prefer an alternative when it fits. Runtime fields, aliases, or snapshot-and-restore often avoid a full reindex.

  • Tune the destination for the copy. On Self-Managed / ECH set number_of_replicas: 0 and refresh_interval: "-1" during the copy, then restore production settings afterward; on Serverless these are managed.

  • Parallelize large copies. Use slices=auto for local reindex and throttle with requests_per_second to protect the cluster.

  • Run big jobs asynchronously. Submit with wait_for_completion=false and poll the task instead of blocking.

  • Verify by count. Compare the source filter expectation to the exact destination GET /{dest}/_count — never estimate.

Operations

HTTP API (shorthand)elastic CLI command
GET /elastic es info
GET /{index}/_mappingelastic es indices get-mapping --index '<index>'
GET /{index}/_countelastic es count --index '<index>'
GET /_cat/count/{index}?h=countelastic es cat count --index '<index>' --h count
PUT /{index}elastic es indices create --index '<index>' --mappings '<json>' --settings '<json>'
PUT /{index}/_settingselastic es indices put-settings --index '<index>' --settings '<json>'
POST /_reindex?wait_for_completion=falseelastic es reindex --wait-for-completion false --source '<json>' --dest '<json>'
GET /_tasks/{task_id}elastic es tasks get --task-id '<task_id>'
GET /_tasks?actions=*reindex&detailedelastic es tasks list --actions '*reindex' --detailed
POST /_tasks/{task_id}/_cancelelastic es tasks cancel --task-id '<task_id>'
POST /_reindex/{task_id}/_rethrottle?requests_per_second=Nelastic es reindex-rethrottle --task-id '<task_id>' --requests-per-second <N>

Files

references/patterns.md

Reindex Patterns

Common multi-step recipes for the Reindex API. Each pattern includes the full sequence of API calls needed.

Pattern 1: Change Mappings on an Existing Index

Use when field types, analyzers, or tokenizers need to change on an index that already contains data. Elasticsearch does not allow altering the mapping of an existing field — reindex into a new index with the corrected mapping, then swap an alias to make the change transparent to clients.

Steps
  1. Create the new index with corrected mappings. On Self-Managed / ECH, include number_of_shards and number_of_replicas: 0 for write throughput. On Serverless, omit both (managed by Elastic):

PUT /my-index-v2
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 0,
    "refresh_interval": "-1"
  },
  "mappings": {
    "properties": {
      "status": { "type": "keyword" },
      "message": { "type": "text", "analyzer": "standard" },
      "@timestamp": { "type": "date" }
    }
  }
}
  1. Reindex from old to new:

POST /_reindex?wait_for_completion=false&slices=auto
{
  "source": { "index": "my-index-v1" },
  "dest": { "index": "my-index-v2" }
}
  1. Monitor until complete, then verify counts (on Serverless, use GET /<index>/_count instead of _cat/count):

GET _tasks/<task_id>
GET _cat/count/my-index-v1?h=count
GET _cat/count/my-index-v2?h=count
  1. Restore production settings (on Serverless, restore only refresh_interval):

PUT /my-index-v2/_settings
{ "number_of_replicas": 1, "refresh_interval": "1s" }
  1. Swap the alias atomically:

POST /_aliases
{
  "actions": [
    { "remove": { "index": "my-index-v1", "alias": "my-index" } },
    { "add": { "index": "my-index-v2", "alias": "my-index" } }
  ]
}
  1. Delete the old index once confirmed:

DELETE /my-index-v1

Pattern 2: Migrate Data from a Remote Cluster

Use when upgrading Elasticsearch across major versions (e.g., 7.x to 9.x) or consolidating clusters. Remote reindex does not support slicing — partition by date range to parallelize.

Steps
  1. Confirm the remote host is allowlisted on the local cluster (reindex.remote.whitelist in elasticsearch.yml). On Serverless, allowlisting is managed internally and only ECH remotes are permitted (Tech Preview).

  2. Create the destination index with mappings compatible with the new version.

  3. Identify a good partition key. For time-series data, use @timestamp ranges. For entity data, use a high-cardinality keyword field.

  4. Reindex one partition at a time (or in parallel):

POST /_reindex?wait_for_completion=false
{
  "source": {
    "remote": {
      "host": "https://old-cluster:9200",
      "api_key": "base64key",
      "socket_timeout": "2m"
    },
    "index": "logs-2025.01",
    "size": 500
  },
  "dest": { "index": "logs-2025.01" }
}
  1. Repeat for each partition. Monitor tasks and verify counts after each completes.

  2. Restore replicas and refresh interval on all destination indices.

Partition strategies
Data shapePartition keyExample query
Time-series (logs, metrics)@timestamp range"range": { "@timestamp": { "gte": "2025-01-01", "lt": "2025-02-01" } }
Entity data (users, products)Modulo on _id or keyword field"script": { "source": "doc['user_id'].value.hashCode() % 4 == 0" }
Per-indexSeparate request per source indexOne POST /_reindex request per source index

Pattern 2b: Copy a Data Stream from ECH to a New Data Stream in Serverless

Use when migrating a complete data stream from Elastic Cloud Hosted (ECH) to a new data stream in a Serverless project. The reindex request runs on Serverless and pulls from the remote ECH cluster. Data streams are append-only, so the destination must use op_type: "create".

Steps
  1. Authenticate to Serverless with an API key. All API calls to Serverless require an API key in the request headers. For the remote ECH connection you can use either an API key or basic auth (username/password) in source.remote.

  2. Create the destination data stream on Serverless. You need an index template that has data_stream: {} and matches the data stream name, then create the data stream. On Serverless omit number_of_shards and number_of_replicas; you can set refresh_interval in the template for backing indices to tune write throughput during the reindex (e.g. "-1"), then restore it after.

    • Create an index template that matches the new data stream (e.g. logs-myapp) with mappings and optional refresh_interval in settings.

    • Create the data stream: PUT _data_stream/<destination-data-stream-name> (or let reindex create it on first document if the template exists and you have the required index privilege).

  3. Run reindex from remote against the Serverless project. Set source.remote.host to the ECH cluster URL, source.index to the ECH data stream name, and dest.index to the Serverless data stream name. Use dest.op_type: "create" — required for any data stream destination because data streams are append-only.

POST /_reindex?wait_for_completion=false
{
  "conflicts": "proceed",
  "source": {
    "remote": {
      "host": "https://your-ech-deployment.es.region.gcp.cloud.es.io:9243",
      "api_key": "<ECH-api-key>",
      "socket_timeout": "2m",
      "connect_timeout": "30s"
    },
    "index": "logs-myapp",
    "size": 500
  },
  "dest": {
    "index": "logs-myapp",
    "op_type": "create"
  }
}
  1. Parallelize with query-based partitioning if the stream is large. Remote reindex does not support slicing. Run multiple reindex requests in parallel, each with a query that partitions the data (e.g. by @timestamp range).

  2. Monitor via GET _tasks/<task_id> (on Serverless you get the task ID from the reindex response; list/cancel may not be available). Verify document count with GET /<data-stream-name>/_count on both ECH and Serverless.

  3. Restore production settings on the destination if you set refresh_interval to "-1" in the template for the reindex (e.g. update the index template or apply settings to existing backing indices as supported).

Pattern 3: Split a Large Index by Date Range

Use when a monolithic index needs to be broken into daily, weekly, or monthly indices to align with ILM policies or data stream conventions.

Steps
  1. Create destination indices with appropriate mappings (or use an index template that matches the naming pattern).

  2. Use a Painless script to route each document to the correct destination index:

POST /_reindex?wait_for_completion=false&slices=auto
{
  "source": {
    "index": "monolith-index"
  },
  "dest": {
    "index": "temp"
  },
  "script": {
    "lang": "painless",
    "source": "def ts = ctx._source['@timestamp']; ctx._index = 'logs-' + ts.substring(0, 10)"
  }
}

This routes documents to indices named logs-YYYY-MM-DD based on the @timestamp value.

  1. The destination index name in the dest field is overridden by the script — the "temp" value is never used. Ensure index templates cover the logs-* pattern so indices are created automatically with correct settings.

  2. Verify document counts across all resulting indices:

GET _cat/count/logs-2025-01-*?h=count

Pattern 4: Merge Multiple Indices into One

Use when consolidating many small indices into a single index for simpler management or improved search performance.

Steps
  1. Create the destination index with mappings that are a superset of all source indices.

  2. Handle ID collisions — documents from different source indices may share the same _id. Append the source index name to make IDs unique:

POST /_reindex?wait_for_completion=false&slices=auto
{
  "conflicts": "proceed",
  "source": {
    "index": ["index-a", "index-b", "index-c"]
  },
  "dest": {
    "index": "merged-index"
  },
  "script": {
    "lang": "painless",
    "source": "ctx._id = ctx._id + '-' + ctx._index"
  }
}
  1. If ID uniqueness is already guaranteed across sources, skip the script and reindex directly.

  2. Alternatively, use "op_type": "create" with "conflicts": "proceed" to keep the first version of each document and skip duplicates.

Pattern 5: Reindex through an Ingest Pipeline

Use when documents need server-side enrichment (GeoIP, user-agent parsing, enrich lookups) or structural transformation (field removal, renaming via rename processor, script processor) during the copy.

Steps
  1. Create (or verify) the ingest pipeline:

PUT /_ingest/pipeline/my-enrich-pipeline
{
  "description": "Add GeoIP and remove sensitive fields",
  "processors": [
    { "geoip": { "field": "client_ip" } },
    { "remove": { "field": "raw_password", "ignore_missing": true } }
  ]
}
  1. Create the destination index.

  2. Reindex with the pipeline:

POST /_reindex?wait_for_completion=false&slices=auto
{
  "source": { "index": "raw-data" },
  "dest": {
    "index": "enriched-data",
    "pipeline": "my-enrich-pipeline"
  }
}
  1. Pipeline processors run on the coordinating node's ingest thread pool. Monitor cluster load and consider requests_per_second throttling if the pipeline is CPU-intensive.

Pattern 6: Performance-Tuned Bulk Reindex

Full recipe for reindexing a large index (100M+ documents) with all performance optimizations applied.

Serverless note: On Serverless, omit number_of_shards, number_of_replicas, and index.translog.* settings (all managed by Elastic). Only refresh_interval is user-configurable. Skip the _forcemerge step — it is not available in Serverless.

Steps
  1. Create the destination index tuned for write throughput. On Self-Managed / ECH use the full settings below. On Serverless, create the index with only refresh_interval in settings (omit number_of_shards, number_of_replicas, and index.translog.*):

Self-Managed / ECH:

PUT /my-large-index-v2
{
  "settings": {
    "number_of_shards": 5,
    "number_of_replicas": 0,
    "refresh_interval": "-1",
    "index.translog.durability": "async",
    "index.translog.flush_threshold_size": "1gb"
  },
  "mappings": { }
}

Serverless:

PUT /my-large-index-v2
{
  "settings": {
    "refresh_interval": "-1"
  },
  "mappings": { }
}

Setting translog.durability to "async" and increasing the flush threshold reduces fsync frequency (Self-Managed / ECH only). Only use these settings during bulk ingest — restore defaults after the reindex.

  1. Run the reindex with all performance options:

POST /_reindex?wait_for_completion=false&slices=auto&requests_per_second=-1
{
  "conflicts": "proceed",
  "source": {
    "index": "my-large-index-v1",
    "size": 5000
  },
  "dest": {
    "index": "my-large-index-v2"
  }
}
  1. Monitor progress:

GET _tasks/<task_id>

Watch status.created and status.total to estimate completion time.

  1. After completion, restore safe settings (on Serverless, restore only refresh_interval):

Self-Managed / ECH:

PUT /my-large-index-v2/_settings
{
  "number_of_replicas": 1,
  "refresh_interval": "1s",
  "index.translog.durability": "request",
  "index.translog.flush_threshold_size": "512mb"
}

Serverless:

PUT /my-large-index-v2/_settings
{
  "refresh_interval": "1s"
}
  1. Force-merge to optimize segment count for read performance (Self-Managed / ECH only — not available in Serverless):

POST /my-large-index-v2/_forcemerge?max_num_segments=1
  1. Verify counts and swap the alias.

Decision Tree: Do I Need to Reindex?

ScenarioReindex needed?Alternative
Change a field's data typeYesRuntime fields (read-only fix, no stored change)
Add a new field to existing documentsYes (if stored)Runtime fields or ingest pipeline on new data only
Change analyzer or tokenizerYes—
Change shard countYes (Self-Managed / ECH)_split or _shrink for simple shard changes (not available in Serverless — shards are managed by Elastic)
Move data to another clusterYes (remote reindex)Snapshot/restore if no transformation needed (Self-Managed / ECH only — not user-accessible in Serverless)
Consolidate many small indicesYes—
Fix a few incorrect documentsNo_update_by_query
Rename an indexNoAlias swap
Filter out deleted documents (reclaim space)Yes_forcemerge?only_expunge_deletes=true (partial reclaim, Self-Managed / ECH only)

Additional examples

Full request examples. See the main skill file for process and CLI mapping.

Full performance-tuned local reindex
POST /_reindex?wait_for_completion=false&slices=auto
{
  "conflicts": "proceed",
  "source": {
    "index": "my-index-000001",
    "size": 5000
  },
  "dest": {
    "index": "my-new-index"
  }
}
Remote reindex with date-range partitioning

Run multiple requests in parallel, each covering a date range:

POST /_reindex?wait_for_completion=false
{
  "source": {
    "remote": {
      "host": "https://remote-cluster:9200",
      "api_key": "<remote-api-key>",
      "socket_timeout": "2m"
    },
    "index": "logs-2025",
    "query": {
      "range": {
        "@timestamp": { "gte": "2025-01-01", "lt": "2025-02-01" }
      }
    },
    "size": 500
  },
  "dest": { "index": "logs-2025" }
}
Reindex with field renaming script
POST /_reindex?wait_for_completion=false
{
  "source": { "index": "events-v1" },
  "dest": { "index": "events-v2" },
  "script": {
    "lang": "painless",
    "source": "ctx._source.event_type = ctx._source.remove('type')"
  }
}
Reindex through an ingest pipeline
POST /_reindex?wait_for_completion=false
{
  "source": { "index": "raw-logs" },
  "dest": {
    "index": "enriched-logs",
    "pipeline": "geoip-and-useragent"
  }
}
Merge multiple indices with ID collision handling
POST /_reindex?wait_for_completion=false
{
  "conflicts": "proceed",
  "source": { "index": ["index-a", "index-b", "index-c"] },
  "dest": { "index": "merged-index" },
  "script": {
    "lang": "painless",
    "source": "ctx._id = ctx._id + '-' + ctx._index"
  }
}

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

The author says: Elasticsearch 8.x or 9.x, self-managed, Elastic Cloud Hosted, or Elastic Cloud Serverless; local reindex works on all deployment types, while remote reindex requires host allowlisting on self-managed / Elastic Cloud Hosted (Serverless supports Elastic Cloud Hosted remotes only, Tech Preview). Requires the `elastic` CLI ≥ 0.2 with `stack es` support.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
elastic
Publisher
Elastic (Official)
Source
elastic/agent-skills · skills/elasticsearch/elasticsearch-reindex · commit 09d879d
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Also distributed in
elastic/agent-skills

AutoGineer is not affiliated with or endorsed by elastic.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download elasticsearch-reindex.zip