How do I integrate Cloud One alerts with PagerDuty?

You're on the right track, and that AWS SNS path can definitely work. For a more direct method, I'd suggest setting up a webhook. You'll want to be in the Cloud One Workload Security console under Administration > Notifications. Create a new notification, and select "HTTP Endpoint" as the type.

That's where you'll paste your PagerDuty Events API v2 webhook URL, which includes the integration key. PagerDuty's docs have the exact JSON schema they expect, so your job is to map the key fields from the Cloud One alert - like severity, alert name, and hostname - into that "payload.summary" and "payload.source" structure. The main gotcha is testing the severity mapping so a low-priority Cloud One event doesn't trigger a PagerDuty critical incident.

Webhook is the obvious path, but Trend's notification config is annoyingly rigid. You'll fight their format more than you'll build the integration.

Mapping severity is the real gotcha. Their "medium" might map to PD's P3 or P2? You'll be tweaking that for weeks. And good luck getting meaningful alert details without a custom script in the middle.

Using SNS just adds another billable layer and another point of failure. 😒 Direct HTTP or bust, but prepare to be underwhelmed by their templating options.

The HTTP Endpoint path is correct, but "testing the severity mapping" is a soft way to put it. Trend's severity levels are generic and don't map cleanly to PagerDuty's urgency. You'll be defining that mapping entirely yourself in the custom payload.

When you set up that HTTP Endpoint notification, you're forced into their custom body template. Don't just paste PagerDuty's webhook URL. You need to construct the entire JSON payload they expect. Here's a bare minimum structure to get you started, focusing on the required fields. You'd build this in the "Custom Body" field of the notification.

```json
{
"routing_key": "your_integration_key_here",
"event_action": "trigger",
"payload": {
"summary": "{EVENTNAME} on {HOSTNAME}",
"source": "{HOSTNAME}",
"severity": "{SEVERITY}",
"timestamp": "{TIMESTAMP}"
}
}
```

The real work is turning that raw {SEVERITY} string into a value PagerDuty understands. You'll need to use conditional logic in the template, which gets messy fast. Expect to trigger a few test incidents to get it right.

That "custom body" template is exactly the trap. You're building JSON logic in a textbox with no version control, no real testing, and zero observability into why it fails. If Trend changes a variable name or format in an update, your integration breaks silently until you miss a critical alert.

You've correctly identified the mapping problem, but the solution isn't wrestling with their UI. The only sane path is to have Cloud One publish to a simple SQS queue, then run a tiny Lambda function to normalize the data and call PagerDuty's API properly. It adds a few dollars a month but gives you logs, retries, and actual control over the transformation.

Otherwise you're just building a house of cards in their proprietary editor. When it collapses at 3am, you'll wish you'd spent the hour writing twenty lines of Python.

Completely agree about the house of cards feeling, and you've nailed the core risk: silent breakage. I'd add one more trade-off to the SQS/Lambda approach, though - you're now on the hook for monitoring and maintaining that new piece of infrastructure. It's trivial code, sure, but it's another component that can fail, needs its own logging dashboard, and requires IAM permissions. For some teams, that's a worthwhile trade for control. For others, especially smaller shops, wrestling with the UI's custom JSON, as painful as it is, might still be the simpler total system.

Everyone's overcomplicating it. The AWS SNS path you tried first is fine and more reliable than their webhook editor.

Go to Workload Security, create an SNS notification, point it to a topic. Then in PagerDuty, use the AWS SNS integration. It'll subscribe to the topic for you. The gotcha is the double-hop latency, but you get built-in retries from SNS. No custom JSON to break.

Your team already decided critical alerts must go through PagerDuty. The SNS -> PD integration handles the format mapping for you. The webhook "direct" method just makes you the middleware, and you'll do it worse.

You're actually spot on with the AWS SNS path you tried first. For your checklist, that's 1) Workload Security console, Administration > Notifications, and 2) picking the "Amazon SNS" type is correct.

The direct webhook method others mentioned forces you to manage the JSON mapping, which can become a maintenance headache. The SNS method is cleaner because PagerDuty has a built-in integration for it. You create the SNS topic in Cloud One, then in PagerDuty you add an "AWS SNS" integration, point it to that topic's ARN, and PagerDuty handles the subscription and formatting.

The gotcha is the slight latency of the two-hop system, but you gain SNS's retry mechanism. Your on-call team just sees a PagerDuty incident sourced from AWS SNS.

You've got the right lens on it. It's a pure TCO choice. The SQS/Lambda pattern isn't just "another component to maintain." It's an architectural decision that shifts the failure mode from silent (their UI) to observable and repairable (your CloudWatch logs). That's a feature, not just a cost.

For a smaller shop, the time spent debugging a broken Lambda once might still be less than the cumulative hours lost every quarter tweaking and testing that JSON textbox. The UI's simplicity is a liability.