Why

Automation jobs in PagerDuty could only receive two pieces of context about the incident they were responding to — no severity, no service name, no alert payload — and users had no way to discover or insert variables without memorizing the syntax.

How

A variable picker built directly into the code editor — letting users browse, search, and insert any field from the triggering alert without leaving their workflow.

Impact

11x increase in actions created with context variables (18 → 198 after one month) · Increased rate of Rundeck Action triggers

Automation jobs could run scripts, pull logs, restart services — but they only knew two things about the incident they were responding to.

Automation Actions let engineers trigger Rundeck jobs directly from an active incident. The jobs could do powerful things — check CPU usage, query databases, retrieve CloudWatch data — but they could only receive two pieces of context: {incident.id} and {user.id}. No severity, no service name, no alert payload. An automation meant to diagnose what went wrong had almost no information about what actually happened.

I was designing for on-call engineers, SREs, and platform teams writing shell scripts and configuring job parameters. That meant respecting their mental models around syntax, arguments, and runtime behavior — while still making the experience discoverable enough that someone new could figure it out without reading documentation first.

The before state — the script editor limited to two hardcoded variables, with the full alert payload visible alongside but completely unreachable from the script.

I mapped the design scope to a single decision node — after the script editor opens and before the action is saved.

Flow diagram isolating the focus: Define Action → Script-or-Rundeck branch → Enter Context Variables → four UI options (Select, Search+Select, Text Input, JSON Selection) → Create Action.

I mapped each approach to existing component patterns to minimize net-new engineering work.

The same flow with concrete component sketches attached — Select maps to a radio list, Search+Select to a searchable checkbox dropdown, Text Input to tag-style chips, and JSON Selection marked N/A.

I researched how developers handle variable insertion in code editors — autocomplete, inline suggestion, and token UI patterns.

Competitive research across developer tools showing four dark-themed code editors with autocomplete and inline suggestion patterns, used to ground the variable picker in familiar engineer mental models.

I explored how to display, type-code, and insert variables — list layouts, inline autocomplete, and a JSON tree picker.

Variable picker explorations iterating on list layouts with color-coded type badges, a script editor with inline autocomplete, and an "Add variable" panel rendering the full JSON payload as a browsable tree.

I prototyped two insertion methods to find which felt most natural for engineers already inside a script editor.

The prototypes pointed toward the same answer: keep users in the editor, and make variable discovery a sidebar — not a separate step.

A split-panel design: the script editor on the left, a browsable variable list on the right — with a toggle between list and raw JSON views.

Early split-panel layout with the script editor on the left and an annotated "Available variables" list on the right, including a toggle for switching between list and raw JSON view.

The variable list supports hover preview and one-click copy — the JSON view exposes the full alert payload as structured sample data.

Interaction spec for list and JSON views across three states each: default listing, hover preview revealing the variable's value, and copy-to-clipboard confirmation.

Variables inserted into the script are highlighted inline — visually distinct from surrounding code so users always know what’s runtime data.

Final script editor with bash CPU/memory code showing context variables — client, event_class, service_group, severity, description — highlighted inline and visually distinct from the surrounding script.

The final design embedded directly into PagerDuty’s existing action creation flow — no new pages, no context switching.

The finished "Create an Automation Action" page with the script editor, inline highlighted context variables, and the "Available variables" panel — all inside the existing three-step wizard.

The system expanded from two hardcoded values to the full alert payload — and actions created with context variables jumped from 18 to 198 in the first month.

Users could now search, read inline descriptions, and insert variables without memorizing syntax. A blind workflow became a guided one.