> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/use-gitops/application/sync-gitops-applications.md).

# Sync GitOps applications

Sync GitOps applications from the Applications page or a GitOps Sync pipeline step, including optional resource-type filters

Sync is a process that ensures that the live state of a system matches its desired state by applying a declarative description. This process synchronizes the desired Git state with the live cluster state.

***

## What you will learn from this topic

* How to [sync a single-source application](#sync-a-single-source-application) from the Applications page or a GitOps Sync pipeline step
* How to set [success criteria](#success-criteria) for the GitOps Sync step
* How to [sync specific resource types](#sync-specific-resource-types-in-the-gitops-sync-step) in the GitOps Sync step
* How to use the [GitOps Sync step parameter reference](#gitops-sync-step-parameter-reference)
* How to [sync a multiple-sources application](#sync-a-multiple-sources-application), [terminate sync](#terminate-sync), and [bulk sync or refresh](#bulk-sync-and-refresh)
* How to configure [sync notifications](#sync-notifications)

***

## Before you begin

Confirm the following before you sync applications:

* **GitOps application**: Create a GitOps application that targets the service, environment, and cluster you intend to sync. Go to [Harness GitOps quickstart](/continuous-delivery/use-gitops/get-started/harness-cd-git-ops-quickstart.md) to create an application.
* **Pipeline alignment (GitOps Sync step)**: When you use the GitOps Sync pipeline step, the service, environment, and cluster selected in the pipeline must match the service, environment, and cluster in the application.
* **Permissions**: Bulk Sync requires the `gitops app sync` permission. Bulk Refresh requires the `gitops app view` permission.
* **Agent version (bulk operations)**: Bulk Sync and Refresh require GitOps agent version 0.93 or higher. An incorrect agent version can cause bulk syncs to time out after three minutes.

***

## Sync a single-source application

You can sync from the **Applications** page or from a pipeline **GitOpsSync** step.

### Sync from the Applications page

Perform the following steps to sync applications from the **Applications** page:

1. In your GitOps project, go to **Deployments** -> **GitOps** -> **Applications**, then select your application.

   ![GitOps Applications list](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-fc65c24f8bbeab3a8dda0858ade504a008667161%2Fsync-applications-3.png?alt=media)
2. Sync the selected application using one of the following paths:
   * Select the more options icon, then select **Sync**.

     ![Sync from the more options menu](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-5911bdb8f4173b31d724aadbfa54702695f6f215%2Fsync-applications-1.png?alt=media)
   * Select the application, then select **SYNC**.

     ![SYNC button on the application](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-d10bf7d19dc958d9720dc9e3703e84cb3a8aa10c%2Fsync-applications-2.png?alt=media)
3. Configure the sync options, then select **Synchronize**.

When you synchronize the application, you can apply a specific revision. By default, Harness selects the target revision of the application.

The **Branch** and **Tag** options display a list of available branches and tags. The **Ref** option lets you synchronize branches, tags, and commit hashes.

![Sync options including revision selection](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-21f1be391ff61f2dafbb5a4aa24b39400d392077%2Fsync-applications-4.png?alt=media)

### Sync with the GitOps Sync step

Perform the following steps to sync applications using the **GitOpsSync** step:

1. Select a pipeline and go to the **Execution** tab of a Deploy stage.

   <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p><strong>Match service, environment, and cluster</strong></p><p>Make sure that the service, environment, and cluster selected in the pipeline match the service, environment, and cluster in the application.</p></div>
2. Select **Add Step**, then select the **GitOpsSync** step.
3. Select the GitOpsSync step to configure step parameters.
4. In **Success Criteria**, select when you want the step to succeed. Go to [Success criteria](#success-criteria) for the available options and how each one affects the rest of the step.
5. Optionally, select **Wait until healthy** if you want the step to run until the application reaches its **Healthy** state. This option applies only when **Success Criteria** is **Sync Succeeded**.
6. Optionally, if you enabled **Wait until healthy**, you can enable **Fail If Step Times Out**. This causes the step to fail if it times out while waiting for the health check to pass.

   <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p><strong>Fail If Step Times Out behavior</strong></p><p>If this option is enabled, the step can sync successfully but still fail if a healthy state is not achieved before the timeout period expires. If this option is disabled, the step is marked successful when the sync succeeds, regardless of the healthy state.</p></div>
7. In **Advanced Configuration**, select the application you want to sync and configure the sync options. You can choose an application or applications manually, or you can match up to 1000 applications using a regex filter. The regex field uses **Go (Golang) regex syntax**, not JEXL. You can test your patterns at [regex101](https://regex101.com/) with the **Golang** flavor selected.

   ![GitOps Sync step regex filter](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-5902a3abf633e7d970a8deab9574e513211a166b%2Fgitopssync-step-regex.png?alt=media)

   To sync only specific resource types instead of the entire application, select **Application Name**, then go to [Sync specific resource types in the GitOps Sync step](#sync-specific-resource-types-in-the-gitops-sync-step).
8. Select **Apply Changes**.

The following image shows how resources look in Harness after the sync process completes.

![Resources after a successful GitOps sync](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-05827c0f486d4e9a4ac3c456ae6681f9cc1e3030%2Fharness-git-ops-application-set-tutorial-40.png?alt=media)

***

## Success criteria

The **Success Criteria** field controls when the GitOps Sync step succeeds.

* **Sync Succeeded** (`syncSucceeded`, default): The step succeeds only after Argo CD reports the sync operation as complete, and, if **Wait until healthy** is enabled, after the application also reaches **Healthy**. This is unchanged from existing behavior, so pipelines that do not set **Success Criteria** are not affected.
* **Sync Initiated** (`syncInitiated`): The step succeeds as soon as Argo CD accepts the sync request. Harness does not poll for the sync operation's outcome or the application's health.

![GitOpsSync step Success Criteria dropdown, showing Sync Succeeded and Sync Initiated options](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-939718dc660a75dbe66f5f62b42a309498ab5f65%2Fgitops-sync-successcriteria.png?alt=media)

Select **Sync Initiated** when a resource in the application's sync wave, such as an Argo Rollout, waits on a manual promotion or an external process that would otherwise keep the sync from ever completing. For example, an application that combines an Argo Rollout with **Prune resources at last** (`pruneResourcesAtLast`) creates an implicit sync wave: pruning cannot run until the rollout finishes, but the rollout is paused waiting on a manual promotion, so the sync never completes and the step times out. **Sync Initiated** is also useful when you validate the sync with your own scripts instead of relying on Harness to poll for health.

With **Sync Initiated**, the step succeeds as soon as Argo CD accepts the sync request, and fails only if the application fails before the request is sent or Argo CD rejects the request.

{% hint style="warning" %}
**Success Criteria has incompatible settings**

**Wait until healthy**, **Show Resource Progress**, and **Select Promote Option for Rollouts** all depend on polling the sync operation after it starts, so none of them work with **Sync Initiated**. Harness disables and resets these fields in the UI when you select **Sync Initiated**, and rejects the combination at save time and at runtime, including when **Success Criteria** or **Wait until healthy** is a runtime input or an expression that resolves to an incompatible combination.
{% endhint %}

Because Harness does not track the outcome of the sync operation when **Success Criteria** is **Sync Initiated**, note the following:

* **No verification of sync completion or health.** A successful step means Argo CD accepted the sync request, nothing more.
* **The application output fields are empty.** `syncStatus` and `syncedRevision` on the step's output applications are `null`, because Harness never observes a post-sync state. An expression that reads either field evaluates to `null`.
* **An in-flight sync is not adopted, but the step still succeeds.** If a sync was already running when the step ran, for example because auto-sync is enabled on the application, the step's own sync request, including its sync options and target revision, was never sent. Harness logs a warning and marks the step successful.
* **Discovered rollouts can be incomplete.** The step still populates `discoveredRollouts` so that a GitOps Rollout step can act on its output, but discovery reads the application's resource tree as of the pre-sync refresh, with no further wait. A commit that lands in the short window between that refresh and the sync request may not be reflected, so `discoveredRollouts` can be partial or empty. A discovery failure logs a warning and does not fail the step.

**Success Criteria** is also available on the [GitOps Rollback step](/continuous-delivery/use-gitops/application/rollback-gitops-applications.md#step-parameter-reference), with the same two values, the same default, and the same restriction against combining **Sync Initiated** with **Wait until healthy**.

**Success criteria examples**

An existing pipeline that does not set **Success Criteria** keeps its current behavior:

```yaml
- step:
    type: GitOpsSync
    spec:
      waitTillHealthy: true
      failOnTimeout: true
```

To trigger a sync without waiting for it to complete:

```yaml
- step:
    type: GitOpsSync
    timeout: 10m
    spec:
      successCriteria: syncInitiated
      waitTillHealthy: false
```

The step succeeds within seconds of Argo CD accepting the sync request, with no completion or health check.

You can set **Success Criteria** and **Wait until healthy** as runtime inputs and resolve them differently per environment, for example `syncInitiated` in a lower environment and `syncSucceeded` in production. Harness allows this at save time, because the incompatible combination is not yet known, and checks it again once the inputs resolve at runtime:

```yaml
- step:
    type: GitOpsSync
    spec:
      successCriteria: <+input>
      waitTillHealthy: <+input>
```

***

## Sync specific resource types in the GitOps Sync step

By default, the GitOps Sync step synchronizes every resource in a GitOps application. Use the **Configure Resources** filter to limit sync to specific Kubernetes resource types, such as `ConfigMap`, `Deployment`, or `ReplicaSet`.

This does not let you cherry-pick individual resources from a list. You select resource types in **Kind**, and optionally narrow the sync with **Group**, **Name**, and **Namespace** patterns. Harness synchronizes all resources in the application that match your filters.

{% hint style="info" %}
**Minimum versions**

This feature requires ng-manager v1.154.0 and next-gen-ui v1.141.0.
{% endhint %}

### Resource filter prerequisites

Confirm the following before you configure resource filters:

* **Manual application selection**: Select **Application Name** in the GitOps Sync step. Resource filters are not available when you target applications with **Application Regex**, **Application Labels**, or **Fetch Linked Apps**.
* **Argo CD behavior**: Resource filtering uses the same capabilities Argo CD provides for selective sync. Any limitation in Argo CD also applies in Harness.

### Configure resource filters

Perform the following steps to configure resource filters:

1. In your pipeline, open the GitOps Sync step.
2. In **Advanced Configuration**, under **Application Selection**, select **Application Name**.
3. Select the GitOps application you want to sync.
4. Select **Configure Resources**.
5. In the **Resource Selection** dialog, set filters for each application row:
   * **Group**: Filter by API group. For example, `apps` or `.*` to match all groups.
   * **Kind**: Select one or more Kubernetes resource types to sync, such as `Deployment`, `ConfigMap`, or `ReplicaSet`. All resources of the selected kinds in the application are synchronized.
   * **Name**: Filter by resource name pattern. For example, `my-app` or `.*`.
   * **Namespace**: Filter by namespace pattern. For example, `default` or `.*`.
6. Select **Save**, then select **Apply Changes** on the step.

![Configure Resources filter in the GitOps Sync step](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-40b43e3f1cf2be693ea2e17e9e7bbcf2d39142b5%2Fgitopssync-configure-resources.png?alt=media)

After the pipeline runs, only resources that match your filters are synchronized. Resources outside the selected kinds or filter patterns remain unchanged by this sync step.

{% hint style="info" %}
**Supported application selection modes**

Resource filters are available only when you select applications by name. They do not work with **Application Regex**, **Application Labels**, or **Fetch Linked Apps**.
{% endhint %}

***

## GitOps Sync step parameter reference

The following YAML example shows GitOps Sync step parameters and common UI field mappings.

<details>

<summary>GitOps Sync step YAML example</summary>

```yaml
- step:
    type: GitOpsSync
    name: GitOps Sync
    identifier: GitOpsSync
    spec:
      applicationsList:                    # UI: "Application Name"  -  auto-populated by Fetch Linked Apps
        - agentId: my-agent
          applicationName: my-app
      # applicationRegex: "^payments-.*"   # UI: "Application Regex"  -  Go regex, max 1000; not JEXL
      # applicationLabels:                 # UI: "Application Labels"  -  Key:Value label selectors
      #   - "env:production"

      prune: false                         # UI: "Prune"  -  delete cluster resources absent from Git
      dryRun: false                        # UI: "Dry Run"  -  preview without applying to cluster
      applyOnly: false                     # UI: "Apply Only"  -  skip pre/post-sync hooks and sync waves
      forceApply: false                    # UI: "Force Apply"  -  delete and recreate instead of patch
      showResourceProgress: true           # UI: "Show Resource Progress"  -  stream per-resource status to logs

      successCriteria: syncSucceeded       # UI: "Success Criteria"  -  syncSucceeded | syncInitiated
                                            # syncInitiated is incompatible with waitTillHealthy: true,
                                            # showResourceProgress: true, and autoPromoteRolloutBehavior

      waitTillHealthy: true                # UI: "Wait until healthy"  -  must be false when successCriteria: syncInitiated
      failOnTimeout: false                 # UI: "Fail If Step Times Out"  -  only meaningful when waitTillHealthy: true
      degradedStateTimeout: "0"            # UI: "Degraded State Timeout"  -  duration string (e.g. "30s", "5m")
                                           # max time app may stay Degraded before step fails; "0" = disabled
                                           # transient degraded states (for example, rolling updates) can trigger this early

      autoPromoteRolloutBehavior: null     # promote-full | resume | retry | abort | restart
                                           # omit if not using Argo Rollouts

      resourcesFilter:                     # scope sync to specific resource types (applicationsList only)
        group: apps
        kind: Deployment
        name: ".*"
        namespace: default
        label: "app=my-app"

      syncOptions:
        skipSchemaValidation: false
        autoCreateNamespace: false
        pruneResourcesAtLast: false
        applyOutOfSyncOnly: false
        replaceResources: false
        serverSideApply: false
        respectIgnoreDifferences: false
        prunePropagationPolicy: foreground # foreground | background | orphan

      retryStrategy:
        limit: 3
        baseBackoffDuration: "5s"
        increaseBackoffByFactor: 2
        maxBackoffDuration: "3m"
    timeout: 10m
```

</details>

**Application selection (use one):**

| Parameter                                    | Type                | Required | Description                                                                                                  |
| -------------------------------------------- | ------------------- | -------- | ------------------------------------------------------------------------------------------------------------ |
| **Application Name** (`applicationsList`)    | `list<object>`      | No       | Explicit `{agentId, applicationName}` pairs. Auto-populated when Fetch Linked Apps ran earlier in the stage. |
| **Application Regex** (`applicationRegex`)   | `string` (Go regex) | No       | Matches up to 1000 app names. Not JEXL.                                                                      |
| **Application Labels** (`applicationLabels`) | `list<string>`      | No       | `Key:Value` label selectors. Partial matches also consider service and environment names.                    |

**Sync behaviour:**

| Parameter                                           | Type      | Required     | Description                                        |
| --------------------------------------------------- | --------- | ------------ | -------------------------------------------------- |
| **Prune** (`prune`)                                 | `boolean` | No (`false`) | Delete cluster resources absent from Git.          |
| **Dry Run** (`dryRun`)                              | `boolean` | No (`false`) | Preview sync without applying changes.             |
| **Apply Only** (`applyOnly`)                        | `boolean` | No (`false`) | Skip pre/post-sync hooks and sync waves.           |
| **Force Apply** (`forceApply`)                      | `boolean` | No (`false`) | Delete and recreate resources instead of patching. |
| **Show Resource Progress** (`showResourceProgress`) | `boolean` | No (`false`) | Stream per-resource sync status to step logs.      |

**Success criteria:**

| Parameter                                | Type | Required             | Description                                                                                                                          |
| ---------------------------------------- | ---- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| **Success Criteria** (`successCriteria`) | enum | No (`syncSucceeded`) | `syncSucceeded` waits for Argo CD to report the sync complete. `syncInitiated` succeeds as soon as Argo CD accepts the sync request. |

For more information, see [Success criteria](#success-criteria) for when to use `syncInitiated` and which other settings it disables.

**Health and timeout:**

The following settings apply only when **Success Criteria** is **Sync Succeeded**.

| Parameter                                           | Type            | Required     | Description                                                                                                                                                       |
| --------------------------------------------------- | --------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Wait until healthy** (`waitTillHealthy`)          | `boolean`       | No (`false`) | Hold step until all synced apps reach `Healthy`.                                                                                                                  |
| **Fail If Step Times Out** (`failOnTimeout`)        | `boolean`       | No (`false`) | When `waitTillHealthy: true`, fail the step if `Healthy` is not reached before timeout.                                                                           |
| **Degraded State Timeout** (`degradedStateTimeout`) | duration string | No (`"0"`)   | Max time app may stay in `Degraded` before the step fails (for example, `"30s"`, `"5m"`). `"0"` disables early-exit. Only evaluated when `waitTillHealthy: true`. |

{% hint style="warning" %}
**Degraded State Timeout**

`degradedStateTimeout` can fire during transient degraded states such as rolling updates where pods are briefly unavailable. Set conservatively or leave at `"0"`.
{% endhint %}

**Sync options** (`syncOptions`):

| Parameter                                                   | Type      | Required          | Description                                                             |
| ----------------------------------------------------------- | --------- | ----------------- | ----------------------------------------------------------------------- |
| **Skip schema validation** (`skipSchemaValidation`)         | `boolean` | No (`false`)      | Skip Kubernetes schema validation before applying.                      |
| **Auto-create namespace** (`autoCreateNamespace`)           | `boolean` | No (`false`)      | Create the destination namespace if it does not exist.                  |
| **Prune resources at last** (`pruneResourcesAtLast`)        | `boolean` | No (`false`)      | Defer pruning until all other resources are applied.                    |
| **Apply out-of-sync only** (`applyOutOfSyncOnly`)           | `boolean` | No (`false`)      | Only apply resources that differ from cluster state.                    |
| **Replace resources** (`replaceResources`)                  | `boolean` | No (`false`)      | Use `kubectl replace` instead of `apply`.                               |
| **Server-side apply** (`serverSideApply`)                   | `boolean` | No (`false`)      | Use Kubernetes server-side apply.                                       |
| **Respect ignore differences** (`respectIgnoreDifferences`) | `boolean` | No (`false`)      | Honor the app's `ignoreDifferences` config during sync.                 |
| **Prune propagation policy** (`prunePropagationPolicy`)     | enum      | No (`foreground`) | How pruned resources are deleted: `foreground`, `background`, `orphan`. |

**Retry strategy** (`retryStrategy`):

| Parameter                                      | Type            | Required | Description                                          |
| ---------------------------------------------- | --------------- | -------- | ---------------------------------------------------- |
| **Limit** (`limit`)                            | `integer` (≥ 0) | No       | Max retry attempts.                                  |
| **Base backoff** (`baseBackoffDuration`)       | duration string | No       | Initial wait before first retry (for example, `5s`). |
| **Backoff factor** (`increaseBackoffByFactor`) | `integer` (≥ 0) | No       | Multiply backoff by this factor on each retry.       |
| **Max backoff** (`maxBackoffDuration`)         | duration string | No       | Backoff ceiling (for example, `3m`).                 |

***

## Sync a multiple-sources application

Go to [Support for Multiple Sources](/continuous-delivery/use-gitops/get-started/harness-cd-git-ops-quickstart.md#step-4-add-a-harness-gitops-application) to create a multi-source application.

After you create an application with multiple sources, you can choose which source to sync with the application during the sync operation. By default, all sources are synced.

Perform the following steps to sync a specific source:

1. Select the **Sync** button in the top right corner of the **Applications** page.
2. Under **Synchronizing application manifest from**, select the source tab from which you want to sync your application.
3. Select the **Sync Source** checkbox. The tab for the selected source, where the checkbox is enabled, is highlighted in green.

![Sync a specific source in a multiple-sources application](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-f8c0a238aeb0af177d548b6f1d3269a039dca3d8%2Fgitops-multiple-sources-sync.png?alt=media)

***

## Terminate sync

To terminate an in-progress sync, go to the application for the syncing app and locate the **Terminate Sync** button in the top right corner of the UI. The **Terminate Sync** button replaces the **Sync** button when a sync is in progress.

![Terminate Sync button on a syncing application](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-891c2f555e28ca8dc404d6c858598bfc3cec5cee%2Fterminate-sync.png?alt=media)

***

## Bulk Sync and Refresh

{% hint style="info" %}
**Minimum agent version**

Bulk Sync and Refresh require GitOps agent version 0.93 or higher. Confirm you have the correct agent version. An incorrect version can cause bulk syncs to time out after three minutes.
{% endhint %}

You can bulk sync or refresh your applications from the applications page. In your GitOps project, go to **Deployments** -> **GitOps** -> **Applications** to open the applications page.

Select **Bulk Sync** in the top left to sync many applications at once, or select **Refresh** in the top right. The following screen appears for bulk sync, and a similar screen appears for refresh:

![Bulk Sync selection and options](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-5d31f4f761ab5d5ab492a61f11eaab21f6d61d89%2Fbulk-sync-reference.png?alt=media)

In the top left you can select all the applications on the page, or you can select applications individually from the list.

On the right you can modify your sync or refresh options. These options apply to all selected applications.

After you select your applications and options, select **Bulk Sync** or **Bulk Refresh**.

{% hint style="warning" %}
**Batch size**

The recommended batch size is 100 applications. To sync more than 100 applications, increase the `GITOPS_AGENT_NUM_PROCESSORS` value in the config by 1 for every additional 100 applications. For example, set it to 2 for 200 applications.
{% endhint %}

Required permissions for bulk operations:

* **Bulk Sync**: You must have the `gitops app sync` permission.
* **Bulk Refresh**: You must have the `gitops app view` permission.

***

## Sync notifications

You can receive notifications for sync success or failure, out-of-sync drift, and health degradation. Go to [Centralised notification](https://developer.harness.io/docs/platform/use-harness-platform/notifications-alerts-and-banners/notifications/centralised-notification#gitops-application-notifications) to configure alerts for GitOps application events.

***

## Troubleshooting

<details>

<summary>Bulk sync times out after three minutes</summary>

Confirm the GitOps agent version is 0.93 or higher. An older agent can cause bulk syncs to time out after three minutes. Also review batch size and `GITOPS_AGENT_NUM_PROCESSORS` if you sync more than 100 applications.

</details>

<details>

<summary>Configure Resources is not available</summary>

Select **Application Name** in the GitOps Sync step. Resource filters are not available with **Application Regex**, **Application Labels**, or **Fetch Linked Apps**.

</details>

<details>

<summary>GitOps Sync step succeeds but the pipeline still fails</summary>

If **Wait until healthy** and **Fail If Step Times Out** are enabled, the step can sync successfully and still fail when the application does not reach **Healthy** before timeout. Adjust timeout settings or disable **Fail If Step Times Out** when sync success alone is enough.

</details>

***

## Next steps

* [Harness GitOps quickstart](/continuous-delivery/use-gitops/get-started/harness-cd-git-ops-quickstart.md): Create GitOps applications, including multiple sources.
* [Centralised notification](https://developer.harness.io/docs/platform/use-harness-platform/notifications-alerts-and-banners/notifications/centralised-notification#gitops-application-notifications): Configure sync and health alerts.
* [Use Harness expressions in GitOps applications](/continuous-delivery/use-gitops/application/use-harness-expressions-in-gitops-applications.md): Parameterize GitOps application configuration.

{% @harness-feedback/feedback %}