Your phone buzzes at 3 AM. PagerDuty. A P1 on the payments service. You reach for it — but there’s already a Slack message in #incidents: root cause identified, draft PR opened, logs linked. An AI agent handled it while you were asleep.

Cursor Automations launched March 5, 2026, and that scenario isn’t a demo. This cursor automations tutorial walks you through building it.

Good prompts are the difference between automations that work and automations that waste your time. Our prompting guide covers the mental model; these examples build on it.

The short version: Cursor Automations let you run AI agents on schedules or events. Connect a trigger (GitHub PR, Slack message, PagerDuty incident), write a prompt describing what the agent should do, enable the tools it needs (Open PR, Send to Slack, MCP), and configure permissions. That’s the whole model.

The question is whether it actually holds up when you wire it into real infrastructure. Let’s find out with three automations you can set up today.

What You Need Before You Start

Cursor Pro or Business plan — automations aren’t available on Free. Not sure if Cursor is the right choice? See how it stacks up against Copilot and Claude Code. A GitHub repo connected to Cursor. Slack workspace admin access if you want Slack triggers (you do). For the incident response automation, you’ll also want a PagerDuty account and Datadog API credentials, but those are optional until Automation 3.

Cost reality: cloud agent minutes bill the same as regular Cursor agent usage. The three automations below run roughly 10–30 agent-minutes per trigger event, depending on your codebase size. At moderate traffic, that’s 200–500 minutes a month — roughly $10–25. Cheaper than the first 30 minutes of your on-call engineer’s time.

You’ve got the accounts. Here’s what to build first.

Automation 1: Security Review on Every Push to Main

This is the lowest-risk entry point. Read-only codebase access, Slack output only, no PR writes. This automates the mechanical security checks that proper code review requires—the stuff human reviewers shouldn’t waste time on. You can watch it run for a week before trusting it with anything else.

Trigger setup: Settings → Automations → New → GitHub → Push to branch → main.

The prompt (copy this verbatim):

Review the pushed diff for: hardcoded secrets, SQL injection vectors,
XSS vulnerabilities, insecure direct object references, and obvious
logic errors.

Post a bullet-point summary to #security-alerts. Tag each finding
as [CRITICAL], [WARNING], or [INFO]. If any [CRITICAL] issues are
found, also leave an inline comment on the commit.

If the diff is clean, post a single message: "Clean push to main —
no issues found."

Tools to enable: Read (codebase access), Send to Slack (point it at #security-alerts), Comment on PR.

Model: claude-sonnet-4-6. Faster than Opus for diff review, strong enough reasoning for security patterns. Haiku is tempting for speed, but it misses subtle injection vectors.

Testing without breaking prod: Change the trigger branch to your feature branch name. Push a commit with a hardcoded API_KEY = "sk-test-123" in a comment. Watch the Slack message arrive. Verify the severity tag is correct. Then switch the trigger back to main.

The most common failure here: the agent can’t post to Slack. The workspace isn’t connected. Settings → Integrations → Slack, run the OAuth flow — it takes two minutes, but it’ll silently fail without it.

Ten minutes, and you’ve got an AI reviewing every push to main for security issues. If you’re already doing code reviews, this catches the mechanical stuff your human reviewers shouldn’t waste time on.

But git events are predictable. What happens when the trigger is a human typing something unexpected into Slack?

Automation 2: Slack-Triggered Bug Triage

Someone posts [BUG] login fails with OAuth on mobile in your #bugs channel. Within two minutes, the agent has searched your codebase, checked recent commits in the auth module, opened a Linear issue with reproduction steps and a suspected root cause, and replied in-thread with a link.

Trigger: Slack → Message posted to channel → #bugs, keyword filter: [BUG]. That filter is important — without it, every message in the channel wakes the agent. Every. One.

The prompt:

Read the Slack message. Extract the bug description and any
error details.

Search the codebase for the relevant module. Check git log for
changes to that area in the past 7 days.

Open a Linear issue with:
- Title: concise bug summary
- Description: reproduction steps (inferred from the report),
  suspected root cause, relevant recent commits
- Label: use existing project labels (check memory for taxonomy)

Reply in the original Slack thread with your findings and
the Linear issue link.

Tools: Read Slack channels, Read (codebase), Open issue (Linear), Send to Slack.

Enable memory. This is where the memory tool earns its keep. Without it, the agent creates Linear issues with inconsistent labels, wrong project boards, and formatting that drifts between runs. With memory, it learns your label taxonomy and project structure. After five or six runs, the issues look like a human filed them.

The dedup problem: Same bug posted twice means two Linear issues. Add this to your prompt: Before creating an issue, search Linear for the error message. If an open issue exists, comment on it instead of creating a new one. Simple fix, but you won’t think of it until the third duplicate.

Slack triggers open up a different category of automation — human-initiated, unpredictable input, context-dependent. The agent handles it because the prompt is specific about what to do with ambiguity.

Git and Slack are covered. But what about when production is actively on fire?

Automation 3: Incident Response That Fixes Itself

This is the 3 AM scenario from the opening. It’s also the most complex automation here — MCP servers, multi-step prompts, environment variables. Set it up after you’ve validated Automations 1 and 2.

Trigger: PagerDuty → Incident triggered. Filter to P1/P2 if you don’t want every alert waking an agent.

MCP setup: Settings → Automations → MCP Servers → Add Datadog. Paste your API key and app key as environment variables ($DATADOG_API_KEY, $DATADOG_APP_KEY) in the automation’s Environment Variables section. Don’t put secrets in prompts — that’s what the env vars are for. Restart Cursor after adding the MCP server.

The prompt:

1. Read the PagerDuty incident title and description.
2. Use Datadog MCP to query error logs from the past 30 minutes
   matching the service name in the incident.
3. Identify the most likely root cause from log patterns.
4. If you can construct a fix with high confidence, open a draft
   PR with the change and a clear commit message.
5. Post to #incidents: incident title, root cause hypothesis,
   PR link (if opened), or next investigation steps (if not).

Tools: MCP server (Datadog), Open pull request, Send to Slack, Read (codebase).

Test this before a real incident teaches you it doesn’t work. PagerDuty’s “Send Test Notification” feature fires a fake incident. Trigger it. Watch the automation run in the dashboard. Verify the MCP connection returns actual log data. If the Datadog query comes back empty, the MCP server isn’t configured right — and you want to find that out now, not at 3 AM.

This is powerful. It’s also the automation most likely to break. Which brings us to the part nobody else covers.

When Automations Go Wrong

Permission errors are the most common failure. The automation can’t push to the repo because the Cursor GitHub app lacks write access. Fix it under your GitHub repo Settings → GitHub Apps → Cursor → Permissions. This trips up almost everyone on the first run.

MCP connection failures. Test the MCP server with a manual agent run before wiring it into an automation. MCP servers timeout at 30 seconds by default — if your Datadog query scans a wide time range on a noisy service, it’ll silently fail.

Wrong output from correct prompts. Before debugging the prompt, check the input. Narrow your trigger filter — add keyword filtering on Slack channels, branch filters on GitHub events. Eighty percent of “wrong output” bugs are actually “wrong input” bugs.

Cost overruns. A broad Slack trigger on a high-traffic channel can burn agent minutes fast. Add a rate limit to the prompt: If more than 3 runs have occurred in the past hour, post a digest summary instead of investigating each message individually.

Every run — success or failure — is logged in the Automations dashboard with duration, token usage, and full output. Check the dashboard before blaming the prompt. If you’ve worked with AI code generation before, you know the pattern: verify the tool’s output before assuming it’s broken.

Start with One, Measure, Then Add

That 3 AM PagerDuty scenario from the opening? It’s Automation 3 above. But don’t start there. Start with the git push security review — it’s read-only, low-risk, and gives you a feel for how automations behave on your codebase before you hand them write access.

Cursor uses the same patterns internally: security review on push to main, agentic codeowners on PR events, incident response on PagerDuty triggers. PlanetScale estimates their Bugbot automation saves the equivalent of two full-time engineers in review effort. The pattern works at scale.

But automations are force multipliers, not replacements for judgment. The prompt still needs to be specific. The tools still need to be scoped tight. And you still need to read the run logs for the first week until you trust the output.

Start with one automation. Watch it run ten times. Fix what breaks. Then add the next one. That’s how you build a system that handles 3 AM incidents — instead of building a system that creates them.