The receiving end of a rule's web request, built and running
A rule's send web request action needs somewhere real to land. We build and host that listener so the webhook actually drives an action downstream instead of going nowhere.
Jira's built-in automation (originally a marketplace app Atlassian bought and folded natively into the product) is a no-code rule engine: pick a trigger like an issue transitioning, add conditions to narrow it, then fire an action like assigning, transitioning, or sending a webhook. It runs at both the global and project level, and it's included free, with the number of rule executions you get per month tied to your plan.
A rule starts with a trigger: an issue created, a field changed, a scheduled time arriving. From there you can stack conditions, checking a field's value, say, before anything fires.
Actions range from the obvious (transition the issue, reassign it, add a comment) to the more powerful send web request action, which lets a rule push data to a URL outside Jira entirely.
Every rule run shows up in an audit log, which makes it straightforward to see what fired, when, and why it did or didn't do what you expected.
A rule's send web request action is only the first half of getting data outside Jira. Something has to actually be listening on the other end, built to parse that payload and do something useful with it.
And every plan tier has a monthly cap on rule executions. A rule that's logically correct can simply stop firing once a team's volume outgrows what their tier allows, quietly, with no obvious error unless someone's watching the audit log.
A rule's send web request action needs somewhere real to land. We build and host that listener so the webhook actually drives an action downstream instead of going nowhere.
When a team's hitting their plan's monthly automation limit, we rebuild the same logic directly on the API, without the cap and without changing what the rule was supposed to do.
Tell us what it's supposed to do, and we'll find out why it isn't, or build past the limit that's stopping it.
Describe what the rule should actually accomplish, inside Jira or beyond it, and we'll build it without the ceiling the built-in version runs into. Jira's automation rules are a good starting point for a lot of teams, and a limited one, same as anywhere else manual work still sneaks back in.
Let's talk →Yes, Jira's built-in automation rules are included free on every plan. The number of rule executions allowed per month scales up as you move to higher plan tiers.
There's no hard limit on the number of rules you can create, but each plan tier caps the total number of rule executions per month across all your rules combined.
Common ones include issue created, field value changed, status transitioned, and scheduled triggers that fire on a recurring timer rather than an event, alongside several others covering comments, versions, and sprint changes.
Yes, through the send web request action, which pushes a payload to a URL you specify. Whatever's on the receiving end of that URL still needs to be built to do something with it.