Set up RuleWatch

What you need

RuleWatch monitors whether a predictable recurring Jira Automation sends its configured success-path heartbeat on time. It does not discover rules or inspect their execution. You need Jira Cloud, a Jira administrator to manage RuleWatch, and permission to edit the intended Automation rule. For Jira alerts, use a project where the app can create a compatible standalone work item and add comments.

Install RuleWatch for Jira from the Atlassian Marketplace once the listing is available. As a Jira or site administrator, approve the requested Jira permissions. Then open Jira settings > Apps > RuleWatch and continue with monitor creation and heartbeat setup below. An existing installation may need an administrator-approved update when permissions change.

Create a monitor

Select Create monitor, give it a descriptive name without sensitive information, and set the expected interval and grace period in minutes. For a rule expected every 60 minutes with 10 minutes of grace, its next heartbeat becomes overdue more than 70 minutes after the last accepted heartbeat. Checks run about every five minutes, so alert detection can be later.

Choose Heartbeat only to track signals without Jira incidents, or enable Jira incident alerts. For alerts, search and select the Jira project, then select a compatible work type. Use the project default assignee or choose an explicitly assignable person through the optional search. A project default can leave the work item unassigned according to Jira configuration.

The read-only configuration check verifies the app's relevant project permissions, work type, required create fields and supported defaults, and the chosen assignee. A required field RuleWatch cannot supply or default makes that destination incompatible. Use a compatible configuration; RuleWatch is not a custom-field editor. Failed lookup or preflight does not replace an existing saved monitor's configuration.

Passing checks cannot guarantee future delivery, every workflow validator or Jira notification. Jira settings and permissions can change. Saving rechecks the destination and creates no Jira work item.

Check Jira delivery

For a monitor with Jira alerts, choose Send test incident and review the confirmation. This deliberately creates one real labeled Jira work item and one labeled test comment. Jira notifications, workflows or project automation may run. Monitoring state stays unchanged; this is neither an outage nor a recovery.

Work-item and comment outcomes are shown separately. Open the linked work item to inspect delivery. RuleWatch retains the latest test result and does not automatically delete or resolve the work item.

Connect the one-time heartbeat

After creating the monitor, copy the URL and complete one-time Bearer value before hiding the setup values. In Jira Automation, add Send web request at the end of the intended successful path:

• URL: the URL shown by RuleWatch.
• Method: POST.
• Body: Empty.
• Header name: Authorization.
• Header value: the complete Bearer secret shown by RuleWatch, including the prefix and space.
• Mark that header Hidden and restrict rule editors.

Do not put the secret in the URL, body, issue content, screenshots or support requests. Anyone holding it can send a false healthy heartbeat. Place the request only after the work whose completion you intend to signal, rather than on an unconditional or failure branch.

Run the intended successful path and inspect the final web request. A 200 response means RuleWatch accepted the heartbeat. Refresh RuleWatch and verify HEALTHY with a last-heartbeat time. Acceptance does not prove the underlying business result was correct.

Read the monitor state

• PENDING: waiting for the first accepted heartbeat. Missing-heartbeat alerts have not started.
• HEALTHY: a heartbeat was accepted within the monitored window. This is an observed signal, not a rule-health guarantee.
• ALERTING: the checker has detected an overdue heartbeat. Review the linked incident or any delivery warning.
• PAUSED: missing-heartbeat checks are suspended.

After the first heartbeat, an overdue monitor with Jira alerts prompts one incident when delivery succeeds. Later checks in that outage do not create duplicates. Heartbeat-only monitors do not create Jira incidents. A missing heartbeat does not identify a root cause: inspect the rule's audit log, intended success path and final request.

A recovery heartbeat returns the monitor to HEALTHY. On a later checker pass, RuleWatch adds one recovery comment to the same incident when delivery succeeds. The work item is not automatically closed or resolved; verify the underlying work separately.

Pause, resume and rotate

Pause a monitor when checks are not wanted. Resuming does not reset its last-heartbeat time. If already overdue, RuleWatch asks you to confirm because the next check may create an incident. Send a fresh heartbeat or adjust the intended configuration before resuming if appropriate.

Use Rotate secret if the credential is lost or exposed. The monitor and URL stay the same, the old secret stops working immediately, and the replacement is shown once. Update the hidden Automation header before the next intended run. A pause can help avoid unwanted alerts while doing this.

Handle failed or uncertain delivery

Read the separate work-item and comment results. A rejected write may require a permission or Jira configuration correction. An uncertain result means Jira may have accepted a write without RuleWatch receiving confirmation. Inspect Jira using the monitor name, time and test reference, then refresh the test result before explicitly requesting another test.

RuleWatch does not automatically repeat an uncertain test write. Do not repeatedly click test to diagnose a timeout. Passing preflight is not proof of later delivery or notification, and a confirmed work item with a failed comment is a partial result. For a missing heartbeat, verify the request's URL, POST method and hidden header without sharing the secret.

Remove a monitor or installation

Delete a monitor to stop accepting its heartbeat and remove its configuration and credential hash. Remove the corresponding Automation request as well. Minimal incident and latest-test records remain until installation cleanup. Existing Jira work items and comments remain under Jira's controls.

Uninstalling RuleWatch requests best-effort cleanup of this installation's app records. Forge's bounded cleanup and hosted-storage retention do not guarantee immediate physical deletion. Reinstallation starts a new storage namespace. See the privacy notice for data handling and retention, or support for safe diagnostics. Never send heartbeat Bearer secrets.