Give Jira a lookout for downtime and recovery

Connect your Jira lookout

Jira Cloud is available on every plan, including Free. The workspace owner opens Account → Integrations → Jira Cloud, enters the root site address such as https://your-team.atlassian.net, and selects Connect Jira. Approve the same site on Atlassian’s consent screen. Your Jira password and API token stay out of UptimeOwl.

Return in the same browser and signed-in session within ten minutes. A green check confirms a saved connection. Check connection verifies access without creating a test ticket.

Choose where tickets land

Search for your project, choose it from the shared dropdown, then choose a standard issue type. More projects and More issue types load another page when needed. Subtasks are not supported.

Enter the exact completion transition name from the Jira workflow, for example Done or Resolve issue. This is the action name, which can differ from the destination status name. It must lead to a completed status and must not require extra fields. Save ticket settings to start automation for new incidents.

The connecting Jira account needs Browse projects, Create issues, Add comments and Transition issues permissions. Summary, Description and Labels must be on the issue’s create screen. Other required fields need Jira defaults; UptimeOwl does not fill custom workflow fields. The completion action is checked against the real issue when recovery occurs.

One incident, one place to follow it

Once the monitor confirms downtime under your detection rules, UptimeOwl queues one Jira issue for that incident. Ongoing failed checks do not create more tickets. Existing open incidents are not imported when you first connect.

When the monitor confirms recovery, the same Jira issue receives a recovery comment. UptimeOwl then uses your configured completion transition. An issue already in a completed status does not need another transition. If the transition is unavailable, the recovery comment remains and Recent deliveries shows what needs attention.

Tickets include the monitor name, event time and an incident reference. Monitor credentials, response bodies and private request headers are not included.

Follow deliveries without extra flapping

Recent deliveries combines Jira and signed-webhook activity, with a service icon and the latest ten entries. Delivery is asynchronous, so it can take a short while. Rate limits and temporary failures are retried.

If Jira might have accepted a request but its response was lost, UptimeOwl checks for the existing issue, recovery comment or completed status. It does not blindly repeat uncertain writes. Leave the UptimeOwl reference label and issue property intact so reconciliation can find the ticket.

If reconciliation cannot confirm the result, delivery eventually shows Needs attention. Check the Jira project or issue before handling it manually. Fixing settings does not replay a failed old delivery or generate a replacement ticket.

Pause, change or disconnect

Turn Integration enabled off to keep the saved settings while pausing new Jira activity. Queued updates from the previous configuration are skipped; turning it on again does not replay a backlog.

Changing the destination, reconnecting or disconnecting retires pending updates for the previous connection. Existing Jira issues remain in Jira, and their remaining recovery work may need manual handling. Reconnecting to another site clears the saved destination.

Suspended workspaces, paused or deleted monitors, maintenance windows and lost owner access prevent queued deliveries. If workspace ownership changes, the new owner must reconnect Jira. Disconnect removes the local connection; you can also revoke UptimeOwl through Atlassian’s connected-app settings.