{"id":4653,"date":"2026-07-24T06:05:19","date_gmt":"2026-07-24T06:05:19","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/07\/24\/from-reactive-monitoring-to-ai-driven-operational-intelligence\/"},"modified":"2026-07-24T06:05:19","modified_gmt":"2026-07-24T06:05:19","slug":"from-reactive-monitoring-to-ai-driven-operational-intelligence","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/07\/24\/from-reactive-monitoring-to-ai-driven-operational-intelligence\/","title":{"rendered":"From Reactive Monitoring to AI-Driven Operational Intelligence"},"content":{"rendered":"<div><img data-opt-id=1342832706  fetchpriority=\"high\" decoding=\"async\" width=\"770\" height=\"330\" src=\"https:\/\/devops.com\/wp-content\/uploads\/2026\/07\/aws_cloudwatch_ai_observability_770x330.jpg\" class=\"attachment-large size-large wp-post-image\" alt=\"\" \/><\/div>\n<p><img data-opt-id=1748528115  fetchpriority=\"high\" decoding=\"async\" width=\"150\" height=\"150\" src=\"https:\/\/devops.com\/wp-content\/uploads\/2026\/07\/aws_cloudwatch_ai_observability_770x330-150x150.jpg\" class=\"attachment-thumbnail size-thumbnail wp-post-image\" alt=\"\" \/><\/p>\n<p>Traditional monitoring often meant chasing alerts and toggling between dashboards after an issue had already impacted users. AWS CloudWatch \u2014 long the backbone of metrics, logs and traces on AWS \u2014 is evolving past that reactive paradigm. The latest CloudWatch capabilities infuse AI-driven operational intelligence into observability, helping engineers surface issues before they escalate and accelerating root cause analysis when incidents occur. Rather than simply visualizing data on dashboards, CloudWatch now provides intelligent insights, anomaly detection and automated investigations. This fundamentally changes the software development engineer (SDE) workflow: Instead of manually correlating metrics and logs in a war room, teams wake up to proactive insights and guided troubleshooting. For AWS builders and architects, the focus shifts from babysitting infrastructure to building with confidence, as CloudWatch\u2019s AI features handle much of the heavy lifting in monitoring and analysis.<\/p>\n<p>In this article, we explore three game-changing advances in CloudWatch\u2019s AI-driven observability suite and how they empower a proactive operations culture:<\/p>\n<ul>\n<li>High-Performance Log Lakes With S3 Tables &amp; Iceberg: Build a scalable, low-cost \u2018log lake\u2019 on Amazon S3 for petabyte-scale analysis of log data.<\/li>\n<li>GenAI Observability: Natively monitor large language model (LLM) usage and retrieval-augmented generation (RAG) pipeline latency using new distributed tracing and curated dashboards.<\/li>\n<li>Automated Root Cause Analysis With Five Whys: Leverage CloudWatch\u2019s AI-assisted \u2018five whys\u2019 incident analysis to drastically cut mean time to resolution (MTTR).<\/li>\n<\/ul>\n<p>Throughout, we\u2019ll maintain a professional, builder-focused lens, offering practical guidance (with console screenshots and code snippets) to implement these features and highlighting how they change day-to-day workflows for SDEs. Let\u2019s dive beyond the dashboards and into the CloudWatch AI revolution.<\/p>\n<h3>Building a Petabyte-Scale Log Lake With S3 Tables and Iceberg<\/h3>\n<p>For several AWS teams, log data is a double-edged sword: It\u2019s incredibly valuable for insights, but retaining and querying massive log volumes in CloudWatch Logs can become slow and expensive. Enter Amazon S3 Tables integration for CloudWatch Logs \u2014 a 2025 feature that lets you offload CloudWatch Logs to an S3-backed data lake in Apache Iceberg format. This integration automatically delivers new log events from CloudWatch to a managed \u2018table bucket\u2019 on S3, where logs are stored as Iceberg tables. In effect, CloudWatch Logs becomes a seamless firehose into your S3 data lake, bridging observability and big-data analytics.<\/p>\n<p>Once ingested into S3, your logs are queryable by a variety of analytics engines (Athena, Amazon Redshift, Spark, etc.) using standard SQL. This means you can run complex aggregations or joins involving log data \u2014 for example, correlating application logs with business data in a data warehouse \u2014 all through familiar query tools. Iceberg\u2019s table format brings schema to semi-structured logs, enabling efficient queries with partition pruning and without needing to manually parse millions of JSON lines. For SDEs, this is a game changer: Instead of writing ad hoc scripts or relying on CloudWatch Logs Insights for each log dive, you can analyze months or years of logs on demand with Athena or Spark, treating logs as another big data source in your lake.<\/p>\n<h3>Performance and Cost<\/h3>\n<p>Amazon S3 Tables are purpose-built for heavy analytics workloads. The S3 Tables service automatically optimizes the underlying Iceberg files with continuous compaction and metadata management. As a result, an S3 Table can handle up to 10\u00d7 higher throughput (\u224855k reads\/sec and 35k writes\/sec per table) compared to a standard S3 bucket used for data lakes. Query performance improves as small log files are merged into larger Parquet files in the background, potentially yielding 3x faster query run times, thanks to fewer overheads. All of this is fully managed \u2014 no EC2 clusters or manual compaction jobs for your team. From a cost perspective, you pay only the normal CloudWatch Logs ingestion fees and S3 storage costs; there is no additional charge to use S3 Tables integration. Given that S3 storage (especially with Intelligent-Tiering) is significantly cheaper per GB than long-term retention in CloudWatch Logs, this approach can slash costs for large log archives while preserving the ability to analyze data whenever needed. In short, you get a high-performance, low-cost log lake solution: CloudWatch handles real-time log ingestion and short-term retention, while S3 + Iceberg serves as the infinite, economical storage for historical analysis.<\/p>\n<h3><strong>Getting<\/strong><strong> S<\/strong><strong>tarted<\/strong><\/h3>\n<p>Setting up the S3 Tables integration is straightforward. In the CloudWatch Logs console, navigate to Settings (Global) and select \u2018Create S3 Table Integration\u2019. You\u2019ll specify an IAM role for CloudWatch to use (to write to S3 on your behalf) and encryption preferences, then associate specific log groups (data sources) with this integration. CloudWatch will create a managed table bucket (named aws-cloudwatch) in S3. Each log group you associate becomes an Iceberg table within that bucket, continuously fed by new log events. On the S3 side, you need to enable Amazon S3\u2019s integration with AWS analytics services (a one-time setup to allow Athena\/Redshift to discover the tables) and configure AWS Lake Formation permissions so your analysts or applications can query the data. Post that, the log data is readily accessible. For example, in Amazon Athena\u2019s query editor, you can switch the data source to \u2018Amazon S3 Tables\u2019 and immediately see databases and tables corresponding to your CloudWatch logs. Standard SQL queries can then be run on your log data \u2013 e.g., to find the top 10 error codes in an Apache access log table:<\/p>\n<p><code>SELECT <\/code><code>error_code<\/code><code>, COUNT(*) AS occurrences<\/code><code>FROM \"prod_webapp__<\/code><code>apache_access_logs<\/code><code>\"<\/code><code>WHERE <\/code><code>error_code<\/code><code> IS NOT NULL<\/code><code>GROUP BY <\/code><code>error_code<\/code><code>ORDER BY occurrences DESC<\/code><code>LIMIT 10;<\/code><\/p>\n<p>Such a query might scan terabytes of log data on S3, yet complete in seconds on Athena due to Iceberg\u2019s optimizations (partitioning, metadata pruning) and the power of serverless Presto. More importantly, this capability means engineers can proactively mine logs for patterns and anomalies at scale \u2014 something not feasible when limited to the 5\u201310 GB ranges of a typical CloudWatch Logs Insights query. Need to analyze a month\u2019s worth of AWS VPC Flow Logs (which could be petabytes) for a security audit? Simply point Athena at the S3 table and crunch away. The S3 log lake decouples compute and storage, so you can retain raw logs for as long as required (compliance, historical trend analysis) without paying a fortune and spin up queries only when needed.<\/p>\n<h3>When to Use S3 Tables for Logs<\/h3>\n<p>Not every team or log source will need this integration, but it shines in a few scenarios:<\/p>\n<ul>\n<li>Long-Term Analytics &amp; ML: You want to retain logs for months\/years and run complex analyses or ML on them (e.g. trend analysis, anomaly detection) beyond what CloudWatch Logs Insights can do.<\/li>\n<li>Join With External Data: You need to join log data with other datasets (CMDB info, business events, etc.) \u2014 easy with SQL in Athena\/Redshift, hard in CloudWatch Logs.<\/li>\n<li>Cost Optimization for Huge Volumes: Your log volumes are extremely large (think TBs per day). Using S3 as a cheap storage tier for logs and querying on demand can drastically reduce costs versus keeping everything hot in CloudWatch or running a giant self-managed ELK cluster.<\/li>\n<\/ul>\n<p>For everyday operational needs, CloudWatch Logs Insights and real-time dashboards still handle recent data and alarms. However, S3 Tables unlock a more proactive, big-picture use of log data. Instead of deleting \u2018cold\u2019 logs or letting them rot in a vault, teams can treat logs as a rich dataset to explore for optimization opportunities, capacity planning and early warning signals. SDEs might, for example, schedule an Athena query to identify unusual spikes in user API errors over the past quarter, or use AWS Glue\/Spark jobs to train a model on historical logs for anomaly detection \u2014 all made feasible by the log lake. The net result is an ops workflow that\u2019s less about reactively grepping yesterday\u2019s logs, and more about continuously gleaning intelligence from all your operational data.<\/p>\n<h3>GenAI Observability \u2014 Tracing LLM Token Usage and RAG Latency<\/h3>\n<p>As generative AI (GenAI) becomes part of our applications (through LLM APIs, Amazon Bedrock, etc.), observability needs to expand beyond CPU and memory. We now care about things such as token counts, model latency and prompt effectiveness. CloudWatch\u2019s new Generative AI Observability feature (GA October 2025) gives AWS builders first-class visibility into these AI-specific metrics. It shifts GenAI monitoring from a manual effort (instrumenting every model call) to an automated, integrated experience. Whether you\u2019re deploying LLMs via Amazon Bedrock or orchestrating complex RAG workflows with LangChain, CloudWatch can natively track the health, performance and cost of your AI services.<\/p>\n<h3>LLM Token Costs Under the Microscope<\/h3>\n<p>Most managed LLMs are billed per token, so a misbehaving prompt or runaway response can burn money quickly. CloudWatch now automatically measures token usage for your Model Invocations. In the Model Invocations dashboard, you\u2019ll find metrics such as Total Tokens Processed, Average Tokens per Request, broken down into input tokens versus output tokens. This granularity means you can monitor not just how many requests you\u2019re serving, but how expensive each request is in terms of tokens. For example, you might discover your average output token count spiked 2x last week, potentially indicating a prompt that is eliciting overly verbose answers (and thus higher cost). By setting up CloudWatch Alarms on these metrics (e.g. alert if average tokens per invocation exceeds a threshold), SDEs can catch cost anomalies early \u2014 before the AWS bill arrives. Moreover, CloudWatch can attribute usage and cost by application, user or even individual prompt if you tag requests, thanks to integration with Bedrock\u2019s Application Inference Profiles and embedded metrics. The outcome is cost transparency for GenAI: Teams know exactly which feature or user segment is driving up LLM costs and can optimize accordingly (such as refining a prompt or caching certain responses).<\/p>\n<h3>RAG Latency and End-to-End Tracing<\/h3>\n<p>RAG pipelines combine an LLM with a knowledge retrieval step (e.g., querying a vector database or search index). This adds new performance considerations \u2014 for instance, a slow vector DB query can bottleneck the whole user request. CloudWatch\u2019s GenAI observability addresses this via end-to-end tracing of prompts and agent workflows. With minimal setup, CloudWatch will capture a distributed trace that follows the flow of a GenAI request: From the initial API call, through any tool or knowledge base lookups, to the final model response. In the CloudWatch console\u2019s GenAI trace view, you can see each segment\u2019s latency. For example, a trace might show: \u2018User query -&gt; Agent invoked -&gt; KnowledgeBase.search() took 120 ms -&gt; LLM.generate() took 800 ms -&gt; Response returned\u2019. Out-of-the-box dashboards highlight overall model latency (average, P90, P99), so you can track customer experience. If tail latency is creeping up, the traces help pinpoint whether it\u2019s the LLM inference time or the retrieval step (or some iterative agent loop) causing the delay. In effect, CloudWatch brings the power of AWS X-Ray to GenAI workflows, with built-in awareness of AI-specific components. An SDE can filter traces by high latency or errors and drill into, say, which queries took unusually long due to multiple tool invocations. This level of insight is crucial for optimizing RAG systems, where latency could come from multiple places (vector index size, prompt complexity, model cold starts, etc.).<\/p>\n<h3>Native Integration Vs. Custom Instrumentation<\/h3>\n<p>If you\u2019re using Amazon Bedrock to host or call models (or its AgentToolkits like AgentCore), CloudWatch GenAI Observability works almost automatically. Bedrock emits the relevant metrics and logs, and CloudWatch organizes them into the Model Invocations and AgentCore dashboards. This includes capturing the content of prompts and responses in curated logs (with redaction for sensitive data), so you can even review what the model was asked and how it answered \u2014 useful for quality and accuracy audits. CloudWatch also supports popular open-source AI frameworks: It\u2019s compatible with LangChain, LangGraph and the Strands Agents SDK out of the box. For example, if you use LangChain\u2019s integration, each step in your chain (LLM call, tool call, memory lookup) can emit trace events that CloudWatch ingests and visualizes, without you writing custom code. Under the hood, this is powered by AWS Distro for OpenTelemetry (ADOT). If you\u2019re rolling your own AI solution (say calling OpenAI\u2019s API directly), you can still leverage CloudWatch by using OpenTelemetry SDK to instrument your code. For instance, you could count tokens from the API response and record a CloudWatch metric ModelTokensUsed on each call or create a trace span around your vector DB query. The new CloudWatch Application Insights for AI will happily ingest those, and they\u2019ll appear alongside Bedrock\u2019s native metrics in a unified view.<\/p>\n<h3>Why This Matters for SDEs<\/h3>\n<p>GenAI observability turns what used to be a blind spot into a source of operational intelligence. In practice, teams have started treating LLM usage as a resource to be managed \u2014 much like CPU or memory. A builder-focused workflow might include: Setting budgets and alerts on LLM usage (e.g., alert if an app uses more than $X in tokens in a day), tracking prompt performance (are new deployments causing higher token counts or error rates?) and monitoring latency versus quality trade-offs (Did that new vector index boost accuracy but also increase latency beyond our SLA?). CloudWatch\u2019s built-in visuals and analytics for GenAI free you from implementing these monitors from scratch. A concrete example: Imagine you deploy a new version of your chatbot that uses a larger model for better answers. CloudWatch\u2019s model dashboard immediately shows that while user satisfaction went up (perhaps measured via a custom metric or lower fallback rate), the P99 latency doubled and the average output tokens went from 200 to 500. With this insight, you might decide to refine the prompt or add caching for frequent queries to tame costs and latency. In essence, AI-driven apps require AI-aware operations, and CloudWatch is providing that in a turnkey fashion \u2014 allowing SDEs to be proactive about cost optimization and performance tuning in the ML domain just as they are with traditional infrastructure.<\/p>\n<h3>Automated Root Cause Analysis With AI and the Five Whys<\/h3>\n<p>Even with the best monitoring, incidents will happen \u2014 and when they do, pinpointing the root cause quickly is paramount. Traditionally, engineers would scramble through logs, dashboards and ticket histories to explain why an outage or alarm occurred. It\u2019s a time-consuming, manual process that prolongs downtime and drags out postmortems. CloudWatch is changing this with AI-powered incident analysis, notably through a feature that applies the \u2018five whys\u2019 technique in an automated, interactive fashion. This approach, inspired by Amazon\u2019s internal correction of error (COE) practice, uses a conversational AI (Amazon\u2019s Q service) to guide engineers through iterative why-questioning until the true root causes are uncovered.<\/p>\n<p>So, what is \u2018five whys\u2019? It\u2019s a classic root cause analysis method where you start with the surface symptom and keep asking \u2018Why did that happen\u2019? \u2014 each answer leads to the next \u2018why\u2019 \u2014 usually about five times, or until you reach a fundamental cause. CloudWatch\u2019s Incident Reports feature now includes a guided \u2018five whys\u2019 workflow that essentially automates this line of inquiry. When an incident occurs (say a high error rate in a service), you can initiate an investigation in CloudWatch, which is a GenAI-driven analysis of correlated telemetry (metrics, logs, traces, AWS CloudTrail events, etc.) around that time. The system will then propose an incident report draft and launch the \u2018five whys\u2019 chat interface. Through a Q&amp;A style chat, it might say: \u201cWe saw 500 errors spiking at 3 a.m. due to database connection failures. Why did the database connections fail?\u201d \u2014 and it will either use data to suggest an answer or prompt the on-call engineer for input. Perhaps you confirm that the database was out of connections. The AI then asks, \u201cWhy were there no available connections?\u201d You dig into logs and find too many batch job opened, and didn\u2019t close them. The chat (which retains context) continues: \u201cWhy did the batch job not close connections?\u201d You realize error handling in that job is flawed. \u201cWhy was the error handling flawed?\u201d It may suggest looking at code review processes, and you conclude that the coding standards didn\u2019t catch this. Finally: \u201cWhy do we lack that check in code reviews?\u201d The answer might be that the team wasn\u2019t aware of this issue due to missing knowledge transfer. Through this dialogue, CloudWatch helps you traverse from a technical trigger to a deeper process or design weakness. In our hypothetical example, the root cause might be summarized as: Inadequate database connection handling in batch job due to gaps in the code review checklist, and the system would then even suggest recommended actions such as implement connection pool monitoring, update code review guidelines to include resource cleanup and add automated tests for connection leaks.<\/p>\n<p>This AI-guided analysis confers several benefits. First, it ensures systematic, thorough investigation rather than a hasty scapegoating of the first obvious failure. By documenting each \u2018Why\u2019 step, it creates a transparent explanation chain that\u2019s invaluable for knowledge sharing and future prevention. Second, it reduces MTTR dramatically. CloudWatch investigations doesn\u2019t wait for you to piece things together; it starts crunching data as soon as an alarm or incident is declared, surfacing correlated anomalies or suspicious events. Many SDEs report that by the time they get to their desk, CloudWatch\u2019s investigation pane has already highlighted, for example, that \u201c90% of the errors came from service X after a deployment at 2:59 a.m.\u201d or \u201clatency spiked on node Y, which had an unusually high GC pause.\u201d This cuts down the time spent simply finding where the problem originated. Then, with \u2018five whys\u2019, the team is guided to dig into the why with AI\u2019s assistance, which keeps the process moving efficiently and not missing key angles. The result is not only faster resolution of the immediate incident, but also actionable insights to prevent it from happening again. CloudWatch\u2019s incident report will capture the entire Q&amp;A and the conclusions, so you have a written record for the post-incident review \u2014 essentially, the AI helps write your RCA document.<\/p>\n<p>From a workflow perspective, SDEs and DevOps engineers will integrate this by triggering CloudWatch investigations automatically on critical alarms. For instance, you might configure a CloudWatch Alarm\u2019s action to start an investigation whenever a web app\u2019s error rate goes above threshold. By the time the on-call engineer responds, the investigation (using GenAI under the hood) might have analyzed logs, metrics and recent deployments to suggest likely causes. The engineer can then use the \u2018five whys\u2019 chat to validate those findings and fill in any gaps (the AI might ask for confirmation or additional context where data is ambiguous). It\u2019s a collaborative human+AI process \u2014 think of it as having a knowledgeable co-pilot in your incident room. This changes the SDE\u2019s role during incidents from \u2018data miner\u2019 to \u2018decision maker\u2019. Instead of spending the first hour of an outage gathering clues, you start with a concise set of clues and hypotheses from CloudWatch. You can focus immediately on confirming the root cause and executing the fix or mitigation, cutting mean time to recovery. One early adopter described it aptly: \u201cCloudWatch\u2019s AI gave me a head start \u2014 it was like coming into a broken system with an expert who had already checked the usual suspects.\u201d After resolution, the \u2018five whys\u2019 report ensures the learnings are recorded and fed back into team practices (e.g. improving a runbook or test coverage), closing the loop on continuous improvement.<\/p>\n<h3>Conclusion: Proactive Ops for the Builder Generation<\/h3>\n<p>\u2018Beyond dashboards\u2019 isn\u2019t just a catchy title; it\u2019s the reality of cloud operations in 2026. AWS CloudWatch\u2019s AI-driven features are transforming observability from a reactive, eyeballs-on-glass exercise into a proactive, insights-driven discipline. For AWS builders and architects, this means your time and talent can be spent on higher-value engineering rather than firefighting or plumbing data pipelines. You can store all your telemetry without breaking the bank (thanks to log lakes on S3) and leverage it for analysis and ML. You gain deep visibility into AI workloads out of the box, ensuring that cutting-edge features such as LLMs remain cost-effective and offer high performance. When things go wrong, CloudWatch\u2019s AI assists in diagnosing and learning from incidents faster than ever, reducing downtime and stress.<\/p>\n<p>Crucially, these advances change the mindset of operations. Instead of asking \u201cIs everything on the dashboard green today?\u201d, teams are asking \u201cWhat can our data tell us next?\u201d and \u201cHow can we prevent the next incident?\u201d The CloudWatch AI revolution enables an \u2018operational intelligence\u2019 approach, where the monitoring system doesn\u2019t just collect data, but interprets it and provides actionable wisdom. SDEs can incorporate this intelligence directly into their workflows: Automated investigations feed JIRA tickets with root cause analysis, anomaly detection alarms prompt code improvements before users notice issues and cost insights from LLM usage guide architectural decisions (like fine-tuning a model or caching results). The result is higher service reliability and performance, achieved not by brute-force manual effort but by smart automation in partnership with AI.<\/p>\n<p>As you adopt these CloudWatch capabilities, keep a builder\u2019s mindset: Experiment and tailor them to your environment. Build that Athena log analysis query that runs every morning to spot weird patterns. Tag your GenAI requests with business context to get richer cost attribution. Trust the \u2018five whys\u2019 process and encourage your team to embrace it, even if it feels different from traditional postmortems. By doing so, you\u2019ll not only solve problems faster, but also systematically harden your systems with each insight gained. The future of observability is proactive and intelligent, and it\u2019s here now in CloudWatch \u2014 enabling us to spend less time watching dashboards and more time building the next big thing.<\/p>\n<p><a href=\"https:\/\/devops.com\/from-reactive-monitoring-to-ai-driven-operational-intelligence\/\" target=\"_blank\" class=\"feedzy-rss-link-icon\">Read More<\/a><\/p>\n<p>\u200b<\/p>","protected":false},"excerpt":{"rendered":"<p>Traditional monitoring often meant chasing alerts and toggling between dashboards after an issue had already impacted users. AWS CloudWatch \u2014 [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4654,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[5],"tags":[],"class_list":["post-4653","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4653","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=4653"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4653\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media\/4654"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=4653"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=4653"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=4653"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}