> For the complete documentation index, see [llms.txt](https://docs.getint.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.getint.io/getintio-platform/workflows/integration-status.md).
# Integration Status
Every integration in Getint has a status that determines whether it is actively synchronizing data. Understanding the two states and how to monitor an integration once it's running is key to keeping your tools reliably in sync.
This page explains both statuses, when to use each, and how to monitor, pause, and recover an integration in day-to-day operation.
### The Two Statuses
#### Enabled
When an integration is set to **Enabled**, it is active and operational. It will synchronize:
* **Newly created items**: tasks, incidents, service requests, bugs, issues, epics, and similar work items created after the integration was set up.
* **Updated items**: changes made to items after the integration was created.
{% hint style="info" %}
**Enabled only covers items going forward**. To transfer historical items that predate the integration, use the **migration** (which is a premium addon) feature instead. This ensures both new and pre-existing data are synchronized.
{% endhint %}
#### Disabled
When an integration is set to **Disabled**, it is inactive. It will **not** process any new or updated items, and no data synchronization occurs while in this state.
Disabling is useful when you need to:
* Pause syncing for maintenance or updates.
* Reconfigure your workflow, mappings, or connected instances safely.
* Temporarily stop sync while troubleshooting an upstream issue in either tool.
When you're ready to resume, switch the status back to **Enabled** to reinitiate synchronization.
{% hint style="warning" %}
Changes made in either tool **while an integration is Disabled are not queued**. Items created or updated during the pause are picked up only if they still qualify on the next run (meaning they were recently modified).
{% endhint %}
### What Happens When an Integration Is Enabled: Runs
An enabled integration does its work through **Runs**. A Run is a cycle in which Getint sends API requests to both connected tools to detect newly created items and recent updates, then synchronizes the changes it finds.
A few things worth knowing about how Runs behave:
* **Integrations run sequentially**: Each integration must finish before the next begins, so your effective sync frequency depends on how many integrations you have and how long each takes.
* **The run interval is a minimum, not a guarantee**: Setting an interval (for example, every 15 seconds) defines the soonest a Run can start again, not a promise it will fire exactly then.
* **Minimum intervals vary by deployment**: Jira Cloud allows a minimum interval of 3 minutes; Jira Data Center typically runs at 60 to 120 seconds; On-Premise can be set as low as 0 seconds.
* **Concurrent edits are merged**: When the same field changes in both tools at once, Getint merges the data to preserve updates and prevent loss.
For a deeper explanation, see [What are Runs?](https://docs.getint.io/getting-started-with-the-platform/about-getint-concepts/what-are-runs) For the difference between ongoing sync and a one-time historical transfer, see [Migration vs Integration](https://docs.getint.io/getting-started-with-the-platform/about-getint-concepts/migration-vs-integration).
### Monitoring a Running Integration
Every Run is recorded and logged in Getint, giving you a clear audit trail of what happened during each synchronization. Use these logs to confirm an integration is healthy and to pinpoint any errors or discrepancies.
When reviewing an integration, the most useful views are:
* **Run history/logs**: the outcome of each Run, including any errors encountered.
* **Latest synced items**: the individual items most recently processed, and the entry point for resyncing a specific item (see below).
A healthy integration shows recent, successful Runs at the expected interval. Long gaps between Runs, or repeated failed Runs, are the first signals to investigate.
### Staying Informed Automatically: Notifications
Rather than checking logs manually, you can have Getint alert you when something needs attention. Getint's **Notifications** can be triggered on events such as **failed runs**, **failed syncs**, **warning logs**, **missing mapping options**, and **integration configuration changes**.
Alerts can be delivered through several channels:
* **Custom SMTP (Email)**: Send through your own mail server.
* **Email (sent by Getint Cloud)**: Minimal setup; available for Jira Cloud apps.
* **Slack**: Push alerts to a channel via a Slack webhook.
* **Webhook**: Send a customizable JSON payload to an external endpoint for real-time integration with your own systems.
This lets you treat the integration's status as something you're notified about, instead of something you have to poll. For full setup steps, see [Notifications](https://docs.getint.io/getintio-platform/notifications).
### Recovering Missed or Failed Items
If an item didn't sync, for example, because it failed on an earlier Run or you've since corrected a mapping, you don't need to edit items by hand in each app. Getint offers two recovery options from the **Latest synced items** view (click the three-dot menu next to an item):
| Option | What it does | When to use it |
| --------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| **Resync** | Marks the item for resynchronization; Getint compares fetched data against its internal database and syncs only the fields that changed. | A specific item didn't sync, or only certain fields (status, assignee, description) need to catch up. |
| **Hard Resync** | Treats **all** fields as modified and forces them to resync, even with no explicit changes. | A more thorough refresh is needed after broader configuration changes. |
| **Recreate** | Allows you to place the failed sync again in the queue for the next synchronization run. | When the cause of the failed sync has been identified, and you want to sync it again with other mappings/options. |
{% hint style="warning" %}
The **Hard Resync will not appear** if the item never successfully created a counterpart on the other side; you will use **Recreate** instead. Resyncs re-process existing pairs; they only sync the latest changes to the work items.
The typical recovery flow is: fix the underlying cause (for example, correct a status mapping), then **Resync**, **Recreate**, or **Hard Resync** the affected item and wait for the next Run. For details, see [Resync and Hard Resync](https://docs.getint.io/getintio-platform/resync-and-hard-resync).
{% endhint %}
### Quick Reference
| | Enabled | Disabled |
| ----------------------- | -------------------------------------- | ------------------------------------------------- |
| **Processes new items** | Yes | No |
| **Processes updates** | Yes | No |
| **Runs execute** | Yes, at the configured interval | No |
| **Historical items** | Use migration (not covered either way) | n/a |
| **Best for** | Normal, ongoing operation | Maintenance, reconfiguration, and troubleshooting |
### Troubleshooting
**My integration is “Enabled” but nothing is syncing**: Check the run history first. If Runs aren't firing, remember integrations run sequentially, so a large number of integrations or a long-running one can delay others. If Runs are firing but an item is missing, it may not meet your filter conditions, or it may have failed on an earlier Run and need a resync.
**An item failed to sync even though everything looks configured correctly**: Correct the underlying issue (a common cause is an inappropriate status or field mapping), then use **Resync** or **Hard Resync** on that item. If the item never created a counterpart on the other side, a Hard Resync won't help, so investigate why creation failed (permissions, required fields) before retrying.
**I paused an integration, and now changes from that period are missing**: Items changed while an integration is Disabled aren't queued. Re-enable the integration, and use a resync for any specific items that didn't get picked up on the next Run.
**I want to know about failures without watching the dashboard**: Set up a **Notification** for failed runs and failed syncs through email, Slack, or a webhook so issues surface proactively.
### Conclusion
An integration's status is the simple on/off switch behind your synchronization: **Enabled** keeps new and updated items flowing through scheduled Runs, while **Disabled** safely pauses everything for maintenance or changes. Pairing the right status with Getint's logs, notifications, and resync tools gives you full visibility and control over your data integration.
For further assistance, please reach out through the [Support Center](https://getint.io/help-center).
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.getint.io/getintio-platform/workflows/integration-status.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.