{"id":446,"date":"2026-04-26T05:00:18","date_gmt":"2026-04-26T05:00:18","guid":{"rendered":"https:\/\/struct.ai\/articles\/automated-cloud-resource-change-alerts\/"},"modified":"2026-09-04T05:04:29","modified_gmt":"2026-09-04T05:04:29","slug":"automated-cloud-resource-change-alerts","status":"publish","type":"post","link":"https:\/\/struct.ai\/articles\/automated-cloud-resource-change-alerts\/","title":{"rendered":"Multi-Cloud Change Alerts: Cut Triage Time by 80%"},"content":{"rendered":"<p><em>Written by: Nimesh Chakravarthi, Co-founder &amp; CTO, Struct | Last updated: August 23, 2026<\/em><\/p>\n<h2>Key takeaways for multi-cloud change alerts<\/h2>\n<ul>\n<li>\n<p>Configure automated cloud resource change alerts by selecting native event sources in each cloud, defining a three-tier severity model, and routing enriched payloads with correlation IDs to your observability and investigation layer.<\/p>\n<\/li>\n<li>\n<p>Map every change event to Critical, High, or Low severity tiers before it reaches your notification channel to keep the paging path narrow while preserving a full audit trail.<\/p>\n<\/li>\n<li>\n<p>Follow the six-step multi-cloud configuration: enable control-plane logs, build severity-scoped event filters, attach correlation IDs and resource tags, route enriched payloads, connect to your automated investigation layer, and test each path end to end.<\/p>\n<\/li>\n<li>\n<p>Measure success by tracking MTTA, MTTR, alert signal-to-noise ratio, and triage time per incident. The 80% triage-time reduction mentioned later becomes achievable when enriched payloads eliminate manual log-hunting.<\/p>\n<\/li>\n<li>\n<p><a target=\"_blank\" rel=\"noopener noreferrer nofollow\" href=\"https:\/\/cal.com\/deepanm\/struct-demo\">Automate your on-call runbook with Struct<\/a> so your team spends less time on cloud change alert triage and more time on engineering work.<\/p>\n<\/li>\n<\/ul>\n<h2>Native tools that surface high-signal cloud change events<\/h2>\n<p>Each major cloud exposes a control-plane log that captures every API call that modifies resources. Pair that log with the cloud&#8217;s native alerting bus and you get a push-based pipeline that fires within seconds of a change, without polling.<\/p>\n<table style=\"min-width: 100px\">\n<colgroup>\n<col style=\"min-width: 25px\">\n<col style=\"min-width: 25px\">\n<col style=\"min-width: 25px\">\n<col style=\"min-width: 25px\"><\/colgroup>\n<tbody>\n<tr>\n<th colspan=\"1\" rowspan=\"1\">\n<p>Cloud<\/p>\n<\/th>\n<th colspan=\"1\" rowspan=\"1\">\n<p>Native Tool<\/p>\n<\/th>\n<th colspan=\"1\" rowspan=\"1\">\n<p>Event Source<\/p>\n<\/th>\n<th colspan=\"1\" rowspan=\"1\">\n<p>Notification Channel<\/p>\n<\/th>\n<\/tr>\n<tr>\n<td colspan=\"1\" rowspan=\"1\">\n<p>AWS<\/p>\n<\/td>\n<td colspan=\"1\" rowspan=\"1\">\n<p><a target=\"_blank\" rel=\"noindex nofollow\" href=\"https:\/\/docs.aws.amazon.com\/awscloudtrail\/latest\/userguide\/cloudtrail-user-guide.html\">AWS CloudTrail<\/a> + <a target=\"_blank\" rel=\"noindex nofollow\" href=\"https:\/\/docs.aws.amazon.com\/eventbridge\/latest\/userguide\/eb-what-is.html\">Amazon EventBridge<\/a><\/p>\n<\/td>\n<td colspan=\"1\" rowspan=\"1\">\n<p>Management events (write + read-write)<\/p>\n<\/td>\n<td colspan=\"1\" rowspan=\"1\">\n<p>SNS \u2192 Lambda \u2192 Slack \/ PagerDuty<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td colspan=\"1\" rowspan=\"1\">\n<p>Azure<\/p>\n<\/td>\n<td colspan=\"1\" rowspan=\"1\">\n<p><a target=\"_blank\" rel=\"noindex nofollow\" href=\"https:\/\/learn.microsoft.com\/en-us\/azure\/azure-monitor\/essentials\/activity-log\">Azure Activity Log Alerts<\/a><\/p>\n<\/td>\n<td colspan=\"1\" rowspan=\"1\">\n<p>Administrative category (write + delete operations)<\/p>\n<\/td>\n<td colspan=\"1\" rowspan=\"1\">\n<p>Action Group \u2192 webhook \u2192 Slack \/ PagerDuty<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td colspan=\"1\" rowspan=\"1\">\n<p>GCP<\/p>\n<\/td>\n<td colspan=\"1\" rowspan=\"1\">\n<p><a target=\"_blank\" rel=\"noindex nofollow\" href=\"https:\/\/cloud.google.com\/logging\/docs\/audit\">GCP Cloud Audit Logs<\/a> + <a target=\"_blank\" rel=\"noindex nofollow\" href=\"https:\/\/cloud.google.com\/monitoring\/docs\">Cloud Monitoring<\/a><\/p>\n<\/td>\n<td colspan=\"1\" rowspan=\"1\">\n<p>Admin Activity audit logs (always on, no charge)<\/p>\n<\/td>\n<td colspan=\"1\" rowspan=\"1\">\n<p>Pub\/Sub \u2192 Cloud Functions \u2192 Slack \/ PagerDuty<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Scope filters to drift from approved infrastructure-as-code identities, approved regions, and approved maintenance windows rather than every configuration change. Within that scoped set, prioritize logging tampering events such as <code>StopLogging<\/code> calls, trail deletion, and disabled GuardDuty detectors, because these are the highest-priority signals and represent an attacker buying time for follow-on activity. The AWS Customer Incident Response Team&#8217;s June 2026 Threat Technique Catalog update reinforces this prioritization by flagging <code>sts:AssumeRoot<\/code> calls and unexpected EKS workload specification changes as additional high-signal events worth adding to your filter set.<\/p>\n<p>Once you have identified which native tools capture the highest-signal events, the next step is to classify those events by severity so your team knows which changes require immediate action versus batch review.<\/p>\n<h2>Severity tiers for IAM, exposure, and deletion changes<\/h2>\n<p>Map every change event to exactly one severity tier before it reaches your notification channel. A three-tier model, with Critical, High, and Low, keeps the paging path narrow while preserving a full audit trail for lower-priority events.<\/p>\n<p>High false-positive rates cause on-call engineers to spend more time reviewing alerts before investigating, which can increase mean time to acknowledge. A tight severity model helps prevent that degradation.<\/p>\n<p><strong>Critical, page immediately:<\/strong><\/p>\n<ul>\n<li>\n<p>IAM events: <code>CreateUser<\/code>, <code>CreateAccessKey<\/code>, <code>AttachUserPolicy<\/code>, <code>UpdateAssumeRolePolicy<\/code>, <code>sts:AssumeRoot<\/code> into member accounts<\/p>\n<\/li>\n<li>\n<p>Public-exposure events: S3 bucket ACL set to public, security group rule opened to <code>0.0.0.0\/0<\/code>, RDS instance with broad internet egress<\/p>\n<\/li>\n<li>\n<p>Logging tampering: <code>StopLogging<\/code>, trail deletion, GuardDuty detector disabled<\/p>\n<\/li>\n<li>\n<p>Deletion of recovery assets: AMI deletion, snapshot deletion on production volumes<\/p>\n<\/li>\n<\/ul>\n<p><strong>High, ticket within SLA for the same shift:<\/strong><\/p>\n<ul>\n<li>\n<p>IAM events created outside the IaC pipeline by a human identity (not deploy automation)<\/p>\n<\/li>\n<li>\n<p>API activity in regions outside your approved footprint<\/p>\n<\/li>\n<li>\n<p>Trust policy modifications on existing roles<\/p>\n<\/li>\n<li>\n<p>New cross-account role assumption variations involving identity provider manipulation<\/p>\n<\/li>\n<\/ul>\n<p><strong>Low, log only for batch review:<\/strong><\/p>\n<ul>\n<li>\n<p>Read-only API calls on non-sensitive resources<\/p>\n<\/li>\n<li>\n<p>Tag updates and metadata changes on non-production assets<\/p>\n<\/li>\n<li>\n<p>Auto-scaling events within approved bounds<\/p>\n<\/li>\n<\/ul>\n<p>The CAGE framework scores each finding across technical severity, asset criticality, exposure context, business impact, and compliance relevance. This framework is a useful reference if you need a weighted formula for borderline events. For most engineering teams at Series A to Series C scale, the three-tier model above is sufficient and faster to maintain.<\/p>\n<h2>Step-by-step: 6-step multi-cloud configuration<\/h2>\n<h3>Step 1, enable and scope your control-plane logs<\/h3>\n<ul>\n<li>\n<p><strong>AWS:<\/strong> Enable CloudTrail in all regions with management event logging set to write-only. Enable S3 data events only for buckets containing sensitive data to avoid log volume explosion.<\/p>\n<\/li>\n<li>\n<p><strong>Azure:<\/strong> Confirm the Activity Log diagnostic setting exports the Administrative, Policy, and Security categories to a Log Analytics workspace.<\/p>\n<\/li>\n<li>\n<p><strong>GCP:<\/strong> Verify Admin Activity audit logs are enabled at the organization level, since they are on by default and free. Enable Data Access audit logs only for services handling regulated data.<\/p>\n<\/li>\n<\/ul>\n<h3>Step 2, build severity-scoped event filters<\/h3>\n<ul>\n<li>\n<p><strong>AWS:<\/strong> Create a CloudWatch metric filter on your CloudTrail log group targeting the Critical IAM API names listed above. Use a filter pattern such as <code>{ ($.eventName = \"CreateUser\") || ($.eventName = \"AttachUserPolicy\") || ($.eventName = \"StopLogging\") }<\/code>.<\/p>\n<\/li>\n<li>\n<p><strong>Azure:<\/strong> Create an Activity Log Alert with condition <em>Operation name<\/em> matching <code>Microsoft.Authorization\/roleAssignments\/write<\/code> and <code>Microsoft.Network\/networkSecurityGroups\/securityRules\/write<\/code> for Critical-tier events.<\/p>\n<\/li>\n<li>\n<p><strong>GCP:<\/strong> Create a Cloud Monitoring log-based metric with a filter such as <code>protoPayload.methodName=\"SetIamPolicy\" AND protoPayload.authorizationInfo.granted=true<\/code> and set an alerting policy on that metric.<\/p>\n<\/li>\n<\/ul>\n<h3>Step 3, attach correlation IDs and resource tags<\/h3>\n<p>Tag every cloud resource with <code>env<\/code>, <code>service<\/code>, <code>team<\/code>, and <code>cost-center<\/code>. Enabling resource tags on telemetry in CloudWatch exposes them as dimensions in Metrics Insights queries, so your alarm notifications automatically include the owning service and environment without manual enrichment. On GCP, use resource labels. On Azure, use resource tags surfaced through the Activity Log&#8217;s <code>resourceId<\/code> field.<\/p>\n<h3>Step 4, route enriched payloads to your notification channel<\/h3>\n<ul>\n<li>\n<p><strong>AWS:<\/strong> Route CloudWatch alarms through Amazon SNS to a Lambda function. The Lambda signs the payload with HMAC SHA-256 and posts to your Slack channel or PagerDuty endpoint. SNS enables retries, fan-out to additional subscribers, and cross-account publishing without altering the original alarm definition.<\/p>\n<\/li>\n<li>\n<p><strong>Azure:<\/strong> Use an Action Group with a webhook action pointing to your incident management endpoint. Chain an Azure Logic App to enrich the payload with recent deployment history before forwarding.<\/p>\n<\/li>\n<li>\n<p><strong>GCP:<\/strong> Route Pub\/Sub messages to a Cloud Functions instance that enriches the payload with the last 15 minutes of error logs and the last 4 hours of deploys before posting to Slack.<\/p>\n<\/li>\n<\/ul>\n<h3>Step 5, connect the enriched payload to your investigation layer<\/h3>\n<p>Point the final webhook destination at Struct or your chosen investigation layer. Struct integrates directly with AWS CloudWatch, GCP Logs, Azure Logs, Datadog, Sentry, and GitHub. When a Critical-tier change alert fires, Struct auto-correlates the change event against live metrics, traces, and recent commits and delivers a root-cause summary before the on-call engineer opens their laptop.<\/p>\n<h3>Step 6, test each alert path end to end<\/h3>\n<ul>\n<li>\n<p>Simulate a Critical event by creating a test IAM user in a non-production account and confirm the alert fires within 60 seconds.<\/p>\n<\/li>\n<li>\n<p>Confirm the Slack notification includes the severity badge, resource ID, correlation ID, owning team, and runbook link.<\/p>\n<\/li>\n<li>\n<p>Confirm the investigation layer receives the payload and begins automated analysis.<\/p>\n<\/li>\n<li>\n<p>Simulate a Low-tier event and confirm it routes to the log stream only, with no page fired.<\/p>\n<\/li>\n<\/ul>\n<p><a target=\"_blank\" rel=\"noopener noreferrer nofollow\" href=\"https:\/\/cal.com\/deepanm\/struct-demo\">See how Struct connects to your cloud change alert pipeline in under 10 minutes<\/a> and automate your on-call runbook.<\/p>\n<h2>Notification payload templates with correlation IDs<\/h2>\n<p>Every notification payload must answer four questions without requiring the engineer to open another tool. The payload needs to show what failed, since when, where to look, and what to do next. Effective alert notifications include the service, SLI or current value versus threshold, a timestamp of first breach, links to dashboards and logs, and a runbook link.<\/p>\n<p>AWS SNS and Lambda enriched payload (JSON):<\/p>\n<pre><code>{ \"severity\": \"CRITICAL\", \"event_name\": \"AttachUserPolicy\", \"actor\": \"arn:aws:iam::123456789012:user\/deploy-bot\", \"resource\": \"arn:aws:iam::123456789012:user\/new-user\", \"region\": \"us-east-1\", \"correlation_id\": \"ct-abc123def456\", \"timestamp\": \"2026-08-23T03:14:22Z\", \"env\": \"production\", \"service\": \"payments-api\", \"team\": \"platform\", \"dashboard_url\": \"https:\/\/console.aws.amazon.com\/cloudwatch\/...\", \"logs_url\": \"https:\/\/console.aws.amazon.com\/cloudtrail\/...\", \"runbook_url\": \"https:\/\/wiki.example.com\/runbooks\/iam-change\" }<\/code><\/pre>\n<p>Azure Activity Log enriched payload (JSON):<\/p>\n<pre><code>{ \"severity\": \"CRITICAL\", \"operation_name\": \"Microsoft.Authorization\/roleAssignments\/write\", \"caller\": \"user@example.com\", \"resource_id\": \"\/subscriptions\/...\/resourceGroups\/prod-rg\/...\", \"correlation_id\": \"az-7f3e9a12-...\", \"event_timestamp\": \"2026-08-23T03:14:22Z\", \"environment\": \"production\", \"service\": \"payments-api\", \"team\": \"platform\", \"dashboard_url\": \"https:\/\/portal.azure.com\/#blade\/...\", \"runbook_url\": \"https:\/\/wiki.example.com\/runbooks\/azure-iam-change\" }<\/code><\/pre>\n<p>GCP Pub\/Sub enriched payload (JSON):<\/p>\n<pre><code>{ \"severity\": \"CRITICAL\", \"method_name\": \"SetIamPolicy\", \"principal_email\": \"deploy-sa@project.iam.gserviceaccount.com\", \"resource_name\": \"projects\/prod-project\/...\", \"correlation_id\": \"gcp-op-9b2c4d...\", \"timestamp\": \"2026-08-23T03:14:22Z\", \"env\": \"production\", \"service\": \"payments-api\", \"team\": \"platform\", \"log_url\": \"https:\/\/console.cloud.google.com\/logs\/...\", \"runbook_url\": \"https:\/\/wiki.example.com\/runbooks\/gcp-iam-change\" }<\/code><\/pre>\n<h2>Incident resolution verification loop<\/h2>\n<p>Incident resolution verification provides closed-loop confirmation that an incident triggered by a cloud resource change is actually resolved, not just acknowledged, by checking live observability data after remediation. Without this step, engineers close tickets based on gut feel and the same root cause recurs.<\/p>\n<p>Struct&#8217;s Incident Tracker, launched August 3, 2026, runs an approximately 1-minute automated verification loop against your observability data after a fix is applied. When a Critical IAM change alert fires and a remediation action is taken, such as detaching an unauthorized policy, Struct queries CloudWatch, Datadog, and Sentry to confirm that error rates, latency, and access-denied events have returned to baseline before marking the incident resolved. This removes the manual &#8220;is it actually fixed?&#8221; check that typically adds 10 to 20 minutes to every incident&#8217;s tail.<\/p>\n<p>The integration path stays straightforward. Your enriched change alert payload with a correlation ID flows into Struct, Struct correlates it against live metrics and traces, surfaces a root-cause summary, and then continuously polls your observability layer post-remediation until the signal clears. The result is a fully documented incident timeline, including change event, investigation, fix, and verification, with no manual steps.<\/p>\n<h2>How to measure 80% triage-time reduction<\/h2>\n<p>Establish a pre-automation baseline before tuning. Track four metrics for 30 days using your existing incident tickets.<\/p>\n<ul>\n<li>\n<p><strong>Mean Time to Acknowledge (MTTA):<\/strong> Teams often target low MTTA, and alert correlation plus deduplication can improve MTTA.<\/p>\n<\/li>\n<li>\n<p><strong>Mean Time to Resolution (MTTR):<\/strong> Elite-performing organizations achieve MTTR under 1 hour, while low performers take over 1 week. SLO-based alerting yields a 25% MTTR improvement, and runbooks for every P1 or P2 alert yield a 30% improvement.<\/p>\n<\/li>\n<li>\n<p><strong>Alert signal-to-noise ratio:<\/strong> Target above 70% actionable alerts. Organizations that implemented alert noise reduction have seen MTTA improvements and lower engineer burnout rates.<\/p>\n<\/li>\n<li>\n<p><strong>Triage time per incident:<\/strong> Measure the clock time from alert fire to root-cause identification. The standard manual baseline is 30 to 45 minutes. Struct customer Arcana cut this from 30 minutes to 2 minutes and reclaims 56 engineer-hours per month across 2,100+ automated investigations.<\/p>\n<\/li>\n<\/ul>\n<p>After implementing the 6-step setup above and connecting an automated investigation layer, re-measure the same four metrics over the next 30 days. The 80% reduction mentioned earlier becomes measurable when the enriched payload eliminates manual log-hunting and the investigation layer delivers a root-cause summary before the engineer&#8217;s first keypress. A GCP-based incident automation system using Cloud Monitoring alerts routed through Pub\/Sub to an orchestrator has reduced MTTR and MTTD substantially, and simply enriching notifications with context, before any auto-remediation, cut MTTR by 40%.<\/p>\n<p><a target=\"_blank\" rel=\"noopener noreferrer nofollow\" href=\"https:\/\/cal.com\/deepanm\/struct-demo\">See the triage-time measurement dashboard in action<\/a> and book a Struct demo to validate your own 80% reduction.<\/p>\n<h2>Frequently asked questions about this setup<\/h2>\n<h3>What is the minimum tooling maturity required before setting up automated cloud resource change alerts?<\/h3>\n<p>Your team needs three things in place before this setup delivers value. You need a cloud control-plane log enabled in every region where you run workloads, such as CloudTrail, Azure Activity Log, or GCP Admin Activity audit logs. You also need at least one alerting destination such as Slack or PagerDuty, and resource tags on production assets that identify the owning service and team.<\/p>\n<p>If those three elements exist, you can complete the 6-step configuration in a single working session. If your logging is incomplete or your resources are untagged, start there, because automated alerts on untagged resources produce noise when the notification cannot identify the owning team or environment.<\/p>\n<h3>How long does it take to roll out this setup across AWS, Azure, and GCP simultaneously?<\/h3>\n<p>A single engineer can complete the Critical-tier filter configuration for one cloud provider in two to four hours, including end-to-end testing. A full three-cloud rollout covering Critical and High tiers typically takes one to two days of focused engineering time. The Struct integration follows the same quick setup path outlined in Step 5, since Struct authenticates directly to your existing observability integrations such as CloudWatch, GCP Logs, Azure Logs, and Datadog without requiring custom middleware. The 30-day noise audit, where you tag every alert as Actionable, Auto-resolved, Duplicate, or Informational, runs in parallel with production traffic and requires no downtime.<\/p>\n<h3>What if our logging and telemetry are incomplete or inconsistent?<\/h3>\n<p>Automated investigation quality is proportional to the quality of your telemetry. If your services emit structured logs with trace IDs and your resources carry consistent tags, the enriched payload will contain enough context for automated root-cause analysis. If logs are unstructured or trace IDs are missing, the investigation layer can still correlate change events against metrics and deployment history, but the root-cause confidence score will be lower.<\/p>\n<p>The practical fix is to add structured logging and a correlation ID header to your highest-severity services first, then expand coverage. Struct&#8217;s investigation rate is 85 to 90% or higher helpful when teams use Sentry, Datadog or cloud logs, and Slack for alerts. That combination is the baseline to target.<\/p>\n<h3>How do we handle compliance requirements around log access and data residency?<\/h3>\n<p>Struct is <a target=\"_blank\" rel=\"noindex nofollow\" href=\"https:\/\/trust.struct.ai\">SOC 2 Type II and HIPAA compliant<\/a> (documented at trust.struct.ai). Logs are accessed and processed ephemerally, and they are not stored by Struct beyond the investigation window.<\/p>\n<p>For teams with strict data residency requirements, scope your CloudTrail, Activity Log, and GCP Audit Log exports to region-specific S3 buckets, Log Analytics workspaces, or GCS buckets that satisfy your residency policy, then point Struct&#8217;s integration at those scoped sources. If your organization requires full on-premises deployment with zero log egress from your VPC, Struct is not currently the right fit, because the platform requires network-level access to your observability integrations to function.<\/p>\n<h3>Can we encode our existing on-call runbooks into the automated investigation flow?<\/h3>\n<p>Struct accepts custom runbook instructions, specific correlation ID formats, and composable widgets that guarantee particular data is always pulled for certain alert types. For example, if your IAM change runbook requires checking the last five deploys, querying a specific DynamoDB table for active sessions, and posting a blast-radius summary to a dedicated Slack channel, you encode those steps once and Struct executes them automatically every time a matching alert fires.<\/p>\n<p>This approach means junior engineers on rotation receive the same starting point a senior engineer would produce manually, without escalation.<\/p>\n<h2>Related reading<\/h2>\n<ul>\n<li>\n<p><a target=\"_blank\" rel=\"noindex nofollow\" href=\"https:\/\/struct.ai\/blog\/automated-root-cause-analysis\">Automated root cause analysis for on-call engineering teams<\/a> \u2014 AI SRE and agentic on-call hub<\/p>\n<\/li>\n<li>\n<p><a target=\"_blank\" rel=\"noindex nofollow\" href=\"https:\/\/struct.ai\/blog\/incident-resolution-verification\">Incident resolution verification: how to confirm an incident is actually fixed<\/a> \u2014 Incident tracking and resolution verification hub<\/p>\n<\/li>\n<li>\n<p><a target=\"_blank\" rel=\"noindex nofollow\" href=\"https:\/\/struct.ai\/blog\/alert-fatigue-sre\">Alert fatigue for SRE teams: causes, costs, and fixes<\/a> \u2014 Alert quality, triage, and fatigue hub<\/p>\n<\/li>\n<\/ul>\n<h2>Conclusion: closing the loop on cloud change alerts<\/h2>\n<p>Manually hunting cloud resource changes at 3 a.m. is a solved problem. A 6-step multi-cloud setup with scoped control-plane logs, a three-tier severity model, enriched payloads with correlation IDs, and a direct handoff to an automated investigation layer cuts triage time from 45 minutes to under 5 minutes and enables incident resolution verification in a single closed loop.<\/p>\n<p>The configuration work is a one-time investment, and the return is measured in engineer-hours reclaimed every month and error budgets that stop burning on avoidable toil. Struct sits on top of your existing observability stack, including Datadog, CloudWatch, GCP Logs, Azure Logs, and Sentry, as the investigation layer that receives your enriched change alert payloads, correlates them against live metrics and code, and verifies resolution automatically. Setup follows the same quick integration path described in Step 5.<\/p>\n<p><a target=\"_blank\" rel=\"noopener noreferrer nofollow\" href=\"https:\/\/cal.com\/deepanm\/struct-demo\">Run your first automated cloud change alert investigation<\/a> and book a Struct demo today.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Set up automated multi-cloud change alerts across AWS, Azure &amp; GCP. Struct helps cut triage time by 80% with severity tiers and correlation IDs.<\/p>\n","protected":false},"author":73,"featured_media":929,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-446","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/struct.ai\/articles\/wp-json\/wp\/v2\/posts\/446","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/struct.ai\/articles\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/struct.ai\/articles\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/struct.ai\/articles\/wp-json\/wp\/v2\/comments?post=446"}],"version-history":[{"count":1,"href":"https:\/\/struct.ai\/articles\/wp-json\/wp\/v2\/posts\/446\/revisions"}],"predecessor-version":[{"id":931,"href":"https:\/\/struct.ai\/articles\/wp-json\/wp\/v2\/posts\/446\/revisions\/931"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/struct.ai\/articles\/wp-json\/wp\/v2\/media\/929"}],"wp:attachment":[{"href":"https:\/\/struct.ai\/articles\/wp-json\/wp\/v2\/media?parent=446"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/struct.ai\/articles\/wp-json\/wp\/v2\/categories?post=446"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/struct.ai\/articles\/wp-json\/wp\/v2\/tags?post=446"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}