feat(alerting): add Jira alerting provider

[ChrisJr404]

Closes #489.

Adds Jira as a new alerting provider, modeled on the existing GitHub provider like the issue suggested. On trigger it creates an issue in the configured project, and when send-on-resolved is set it looks up the matching open issue(s) and moves them through the configured transition (Done by default) once the alert resolves. Authentication is basic auth with an account email and an API token.

Config is minimal to get started:

alerting:
  jira:
    base-url: "https://your-domain.atlassian.net"
    username: "you@example.com"
    token: "your-api-token"
    project-key: "OPS"

issue-type (default Task) and resolve-transition (default Done) are optional. Added unit tests covering create/resolve/error paths and README docs.

[TwiN]

LGTM, great work!

[Copilot]

🟡 Changes recommended

The Jira resolve path can miss the matching issue due to unbounded/paginated search results, and several error paths omit Jira’s response body, making failures hard to diagnose.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Adds a new Jira alerting provider to Gatus’ alerting subsystem, wiring it into config validation/registration and documenting its configuration in the README.

Changes:

• Introduces jira as a new alert type and registers it across alerting/config, provider registry, and config validation.
• Implements the Jira provider logic (create issue on trigger; search + transition issue(s) on resolve) with unit tests.
• Documents Jira alerting configuration and options in the README.

File summaries

File	Description
README.md	Adds “Configuring Jira alerts” documentation and config key reference entry.
config/config.go	Registers alert.TypeJira in alerting validation.
alerting/provider/provider.go	Registers Jira provider in the provider registry and compile-time interface checks.
alerting/provider/jira/jira.go	Implements Jira provider config validation + create/resolve (transition) logic.
alerting/provider/jira/jira_test.go	Adds unit tests for Jira provider create/resolve/error paths and config overrides.
alerting/config.go	Adds Jira *jira.AlertProvider to the alerting config struct.
alerting/alert/type.go	Adds new alert type constant TypeJira.

Review details

Suppressed comments (3)

alerting/provider/jira/jira.go:144

• When searching issues fails, returning only the status code hides Jira's error details (JQL parse errors, auth failures, permission issues). Read and include the response body in the returned error.

	if response.StatusCode >= 400 {
		return fmt.Errorf("failed to search issues, status: %d", response.StatusCode)
	}

alerting/provider/jira/jira.go:175

• When fetching available transitions fails, Jira typically provides useful details in the response body (e.g., missing transition permissions). Include the response body in the error message to aid debugging.

	if transitionsResponse.StatusCode >= 400 {
		return fmt.Errorf("failed to fetch transitions for %s, status: %d", issueKey, transitionsResponse.StatusCode)
	}

alerting/provider/jira/jira.go:206

• When transitioning the issue fails, Jira's response body often includes the reason (invalid transition ID, missing fields, permissions). Include the response body in the error message for easier troubleshooting.

	if response.StatusCode >= 400 {
		return fmt.Errorf("failed to transition issue %s, status: %d", issueKey, response.StatusCode)
	}

• Files reviewed: 7/7 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[TwiN]

@ChrisJr404 would you mind looking into copilot's suggestions? I don't have a jira instance I can validate those on, nor am I super familiarwith Jira's API

[ChrisJr404]

Done. Pushed a commit that addresses both of Copilot's points:

• The create/search/transition error paths now include the Jira response body, so JQL parse errors, auth failures, and invalid-transition responses actually show up in the error message.
• The resolve path now pages through the search results (startAt/maxResults) instead of relying on a single page, so a matching issue won't be missed on projects with a lot of open issues.

No live Jira instance needed on your end; the existing unit tests cover the create/resolve/error paths and still pass.

[ChrisJr404]

Both of Copilot's points are reasonable:

1. Pagination on resolve: rather than fetching all non-Done issues and filtering the summary in-memory (which misses matches past the first page), I can narrow the JQL to the exact summary and request only the fields I need, so resolution does not depend on page size.
2. Error detail: I can include Jira's response body in the returned errors, since that is where the actionable detail (permissions, invalid issue type) usually is.

Neither needs a live Jira to reason about. Want me to push those two changes on top, or would you rather merge as-is and iterate?