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.
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.
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).
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? For the difference between ongoing sync and a one-time historical transfer, see 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.
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.
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.
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.
Last updated
Was this helpful?