# Post Mortem A structured process following a technical incident that reviews what occurred, why it happened, how it was resolved, and how to prevent recurrence. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## OpenAI and Hugging Face partner to address security incident during model evaluation DevFeed: [OpenAI and Hugging Face partner to address security incident during model evaluation]() Original publisher: [Read original article]() Published: 2026-07-21T07:00:00Z Content type: article Language: en Sources: [OpenAI News]() Topics: [incident](), [hugging face](), [Security](), [Vulnerabilities](), [Artificial Intelligence](), [OpenAI](), [LLM evaluation / benchmarking](), [Incident response](), [Post Mortem]() Tags: [ai](), [evaluation](), [hugging-face](), [incident](), [incident-response](), [openai](), [post-mortem](), [security](), [vulnerabilities]() ### AI overview OpenAI and Hugging Face share findings from a security incident that occurred during AI model evaluation. The updates describe a platform-level compromise, exploitation of a previously unknown Artifactory vulnerability, exposed credentials used by models, and ongoing third-party assessment and incident-response work. ### Source excerpt OpenAI and Hugging Face share early findings from a security incident during AI model evaluation, highlighting advanced cyber capabilities and lessons for defenders. ## Post-mortem GPU crash debugging with LLMs DevFeed: [Post-mortem GPU crash debugging with LLMs]() Original publisher: [Read original article]() Author: Amit Ben-Moshe; Amit Mulay Published: 2026-07-14T12:00:00Z Content type: article Language: en Sources: [AMD GPUOpen]() Topics: [GPU](), [debugging](), [Model Context Protocol](), [MCP Server](), [Large Language Model](), [Code](), [Post Mortem]() Tags: [announcement](), [coding-agents](), [debugging](), [getting-started](), [gpu](), [gpu-open-tools](), [gpuopen-third-party](), [gpuopen-tools](), [graphics-apis](), [llms](), [mcp](), [mcp-server](), [memory](), [microsoft](), [ml](), [news](), [product-release](), [quick-start](), [radeon-developer-tool-suite](), [radeon-gpu-detective](), [rdts](), [rgd](), [root-cause-analysis](), [technical-article](), [technical-articles](), [third-party](), [tools](), [user-guides-manuals]() ### AI overview This article introduces the open-source AMD Radeon GPU Detective MCP Server, which gives LLMs structured access to GPU crash dumps and application source code for post-mortem debugging. It describes a workflow in which an LLM investigates crash evidence and suggests source-code fixes through a single natural-language prompt. ### Source excerpt The new AMD RGD MCP Server connects LLM agents to AMD's GPU crash analysis pipeline, turning a single prompt into root-cause analysis and source-code fix suggestions. ## Post Mortem: HTTP Request Smuggling Vulnerability DevFeed: [Post Mortem: HTTP Request Smuggling Vulnerability]() Original publisher: [Read original article]() Author: Julien Portalier Published: 2026-05-26T00:00:00Z Content type: article Language: en Sources: [Crystal]() Topics: [Post Mortem](), [vulnerability](), [Crystal](), [HTTP](), [Security](), [Exploit]() Tags: [2026](), [access-control](), [http](), [post-mortem](), [rate-limiting](), [security](), [server](), [vulnerability]() ### AI overview This post-mortem describes an HTTP request smuggling vulnerability in Crystal's HTTP server. The parser mishandled requests containing conflicting framing headers, allowing request injection between a reverse proxy and a Crystal server under specific proxy conditions. The issue was patched in Crystal 1.20.0 and 1.19.2. ### Source excerpt On 12 April 2026, we received a vulnerability report regarding an HTTP request smuggling vulnerability in HTTP::Server. ## Adaptable apps on ChromeOS: a post-mortem DevFeed: [Adaptable apps on ChromeOS: a post-mortem]() Original publisher: [Read original article]() Author: Thomas Künneth Published: 2026-05-23T11:26:02Z Content type: article Language: en Sources: [Thomas Künneth]() Topics: [Post Mortem](), [chromebook](), [Android](), [App](), [Development]() Tags: [android](), [app](), [chromeos](), [coding](), [community](), [dev](), [development](), [engineering](), [inclusive](), [post-mortem](), [software](), [uidesign]() ### AI overview A post-mortem of attempts to remove ChromeOS's resize confirmation for the Be nice Android app in ARC windows. The article explains how the warning appears in windowed laptop mode, why manifest changes did not remove it on Play Store builds, and how tablet mode differs. ### Source excerpt In my previous article Building a custom launcher for ChromeOS I described how Be nice runs on Chromebooks: not as a real default home app, because default home settings (Settings.ACTION_HOME_SETTINGS) usually are not available on ChromeOS, but as a normal Android app in an ARC window. I pretended the app is the launcher in code (detectIsHomeApp() returns true on ChromeOS), worked around split-screen bugs that leave the app a black rectangle, and gave up transparent wallpaper for an opaque scaffold because ARC does not show the ChromeOS desktop behind the window the way a phone shows its wallpaper. What that article obviously could not cover is the fight that came right after. For about a week in May 2026 I tried to get rid of a system confirmation ChromeOS shows when users open the preset-size menu in the ARC window title bar and choose Resizable, at least on Play Store builds. During my experiments, manifest changes often looked fine from Android Studio; however, on Play, the dialog stayed. I tried adding XML, asking AI assistants, including Google's own models, for the magic flag. Here's what I learned along the way. What users see ChromeOS does not present Play Store Android apps the same way in every posture. On a convertible or clamshell Chromebook in laptop use, ARC usually places apps in individual windows (chromeos.dev). The title bar often labels the current layout (Phone, Tablet, or Resizable) and opens a menu to switch presets; choosing Resizable is what triggers the warning below, not dragging the window frame by itself (in fact, resizing the window by dragging one of the window edges does not work until it is allowed through the dialog). In tablet mode the picture is different: apps commonly launch and stay full screen, which matches how ChromeOS has long treated touch-first use on detachables (Chrome Unboxed on immersive mode). The resize presets and the warning below matter most when you are in a windowed, laptop-style layout, not when an app is alre ## What does using AI for post-mortems actually mean? DevFeed: [What does using AI for post-mortems actually mean?]() Original publisher: [Read original article]() Author: incident.io Published: 2026-04-23T14:29:00Z Content type: opinion Language: en Sources: [The incident.io Blog]() Topics: [Artificial Intelligence](), [Post Mortem](), [Incident response](), [incident](), [Compression](), [Slack]() Tags: [ai](), [channel](), [compression](), [docs](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [outage](), [post](), [post-mortem](), [slack](), [slack-incident](), [thread]() ### AI overview The article argues that AI can make post-mortems faster by gathering Slack threads, timelines, pull requests, and custom fields into a useful starting point. However, it warns that polished AI-generated documents can become useless if they replace the team's work of understanding what happened, why it happened, and what was learned. It distinguishes compression, which AI can automate effectively, from synthesis, which requires genuine human reasoning. ### Source excerpt Everyone is using AI to help with post-mortems now. We've built AI into our own post-mortem experience, pulling your Slack thread, timeline, PRs, and custom fields together and giving your team a meaningful starting point in seconds. But "AI for post-mortems" can mean very different things. Post-mortems are just one stage of the broader incident response lifecycle, and AI's role varies across all of it. ## Why post-mortem action items die DevFeed: [Why post-mortem action items die]() Original publisher: [Read original article]() Author: Kate Bernacchi-Sass Published: 2026-04-16T13:55:19Z Content type: opinion Language: en Sources: [The incident.io Blog]() Topics: [Post Mortem](), [incident](), [Incident response](), [Monitoring]() Tags: [incident](), [incident-channel](), [incident-management](), [incident-response](), [monitoring](), [on-call](), [outage](), [post-mortem](), [slack-incident](), [technical]() ### AI overview The article explains why post-mortem action items often fail after incident debriefs. It identifies unclear ownership, storage outside the team's normal work tools, vague directions instead of verifiable tasks, and lack of follow-up checks as common failure modes. ### Source excerpt You can run the best debrief of your life. Honest timeline, blameless tone, real insights. People leave the room nodding. And then nothing happens. Here's how to fix that. ## Wayland set the Linux Desktop back by 10 years DevFeed: [Wayland set the Linux Desktop back by 10 years]() Original publisher: [Read original article]() Author: Omar Roth (blog@omar.yt) Published: 2026-03-18T11:40:32Z Content type: opinion Language: en Sources: [Omar Roth]() Topics: [Wayland](), [Linux](), [Post Mortem]() Tags: [developer](), [linux](), [post-mortem](), [wayland]() ### AI overview An opinionated engineering post-mortem argues that Wayland misdirected developer effort and harmed Linux desktop users. It frames the discussion around the limitations of existing systems, why they may not be fixable, and the goals and expected timeline of a new project. ### Source excerpt Wayland has been a broad misdirection and misallocation of time and developer resources at the expense of users. If you're not familiar with this space, hopefully it will still be interesting as an engineering post-mortem on taking on new greenfield projects. Namely: What are the issues with what exists, why can they not be fixed, what do we hope to achieve with a new project, and how long do we expect it to take? ## We rebuilt our post-mortems from the ground up DevFeed: [We rebuilt our post-mortems from the ground up]() Original publisher: [Read original article]() Author: Pete Hamilton Published: 2026-03-17T13:30:00Z Content type: release Language: en Sources: [The incident.io Blog]() Topics: [Post Mortem](), [incident](), [Slack](), [real-time](), [Tooling](), [Artificial Intelligence]() Tags: [ai](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [new-feature](), [outage](), [post](), [post-mortem](), [real-time](), [slack](), [slack-incident](), [tooling]() ### AI overview incident.io announces a rebuilt post-mortems experience designed to reduce the effort of drafting, maintaining, collaborating on, and managing post-mortems. The update brings incident data into a synced editor, supports AI-assisted post-mortem workflows, enables real-time collaborative editing and threaded comments, and adds tooling for tracking post-mortem status, overdue work, and readership at scale. ### Source excerpt Today we're launching our new post-mortems experience, and I want to walk you through what we've done and why. ## The post-mortem problem DevFeed: [The post-mortem problem]() Original publisher: [Read original article]() Author: incident.io Published: 2026-03-04T19:36:00Z Content type: article Language: en Sources: [The incident.io Blog]() Topics: [Post Mortem](), [Software Engineering](), [incident]() Tags: [culture](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [outage](), [post-mortem](), [slack-incident](), [software-engineering](), [writing]() ### AI overview The article argues that post-mortems often fail because they become compliance artifacts instead of useful parts of the incident response lifecycle. It examines timing, overly demanding templates, the difficulty of post-mortem writing, and organizational culture, emphasizing that effective documents preserve context, explain technical events clearly, and support learning. ### Source excerpt Post-mortems are one of the most consistently underperforming rituals in software engineering. Most teams do them. Most teams know theirs aren't working. And most teams reach for the same diagnosis: the templates are too long, nobody has time, nobody reads them anyway. ## IA en sysadmin: ¿oportunidad o amenaza? DevFeed: [IA en sysadmin: ¿oportunidad o amenaza?]() Original publisher: [Read original article]() Author: Alois Published: 2026-01-13T00:00:00Z Content type: opinion Language: es Sources: [tengoping.com]() Topics: [AIOps](), [datacenter](), [Infrastructure as code](), [Terraform](), [Ansible](), [Command-line interface](), [Post Mortem](), [telemetry]() Tags: [aiops](), [ansible](), [datacenter](), [iac](), [logs](), [post-mortem](), [sysadmin](), [terminal](), [terraform]() ### AI overview This Spanish-language article examines how AI can assist systems administrators with log triage, anomaly detection, IaC manifest generation, incident summaries, runbook drafts, and command suggestions. It argues that AI reduces mechanical work but does not replace human diagnosis, review, or operational judgment. ### Source excerpt Reflexión sobre dónde ayuda la IA al sysadmin, qué riesgos reales conlleva en producción y cómo adaptarse sin perder criterio. ## Beyond Detection: Building a Resilient Software Supply Chain (Lessons from the Shai-Hulud Post-Mortem) DevFeed: [Beyond Detection: Building a Resilient Software Supply Chain (Lessons from the Shai-Hulud Post-Mortem)]() Original publisher: [Read original article]() Author: Liran Tal Published: 2026-01-08T05:00:00Z Content type: article Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [Post Mortem](), [supply-chain-security](), [incident](), [npm](), [Security](), [Malware](), [AI-assisted coding](), [ci](), [GitHub Copilot](), [Vulnerabilities]() Tags: [ai-coding](), [americas](), [awareness](), [blog](), [ci](), [ci-cd](), [copilot](), [developer](), [devops](), [github](), [github-copilot](), [google](), [incident](), [interest](), [javascript](), [malware](), [node-js](), [post-mortem](), [related-content](), [security](), [security-labs](), [snyk-apprisk](), [snyk-code](), [snyk-open-source](), [snyk-platform](), [snyk-security-intel](), [supply-chain](), [tech](), [vulnerabilities]() ### AI overview The article examines the Shai-Hulud npm supply chain incident and argues that organizations should move beyond reactive scanning toward layered prevention, real-time intelligence, and automated action. It highlights safer dependency upgrades, a 21-day cooldown strategy, and security guardrails embedded in AI coding workflows. ### Source excerpt The Shai-Hulud npm incident exposed the limitations of reactive security in modern software supply chains. To survive the next major attack, organizations must shift toward a multi-layered strategy of proactive prevention, real-time intelligence, and automated action. ## Reliability lessons from the 2025 Cloudflare outage DevFeed: [Reliability lessons from the 2025 Cloudflare outage]() Original publisher: [Read original article]() Author: Andre Newman Published: 2025-11-20T00:00:00Z Content type: article Language: en Sources: [Gremlin Blog]() Topics: [Cloudflare](), [Bot Management](), [configuration](), [Chaos Engineering](), [Post Mortem](), [Network](), [Workers]() Tags: [2025](), [after-the-retrospective](), [bot-management](), [chaos-engineering](), [cloudflare](), [configuration](), [engineering](), [http](), [internet](), [management](), [outage](), [outages](), [post-mortem](), [workers]() ### AI overview The article examines the November 2025 Cloudflare outage, explaining how an oversized Bot Management configuration caused HTTP 5XX errors and cascading failures across dependent services. It highlights configuration propagation, service dependencies, and chaos engineering as reliability considerations. ### Source excerpt In November 2025, a misconfigured Cloudflare service led to a partial outage. Learn what happened, and what you can do to reduce the impact of similar outages. ## Auto Update Post-Mortem DevFeed: [Auto Update Post-Mortem]() Original publisher: [Read original article]() Author: Conrad Irwin Published: 2025-09-12T00:00:00Z Content type: opinion Language: en Sources: [Zed Industries - Blog]() Topics: [Post Mortem](), [bug](), [JSON](), [Testing](), [Slack]() Tags: [bug](), [json](), [post-mortem](), [slack](), [testing]() ### AI overview Zed explains how a settings-parsing change broke automatic updates in production for versions 0.203.0-0.203.4 and 0.204.0. The article identifies the fallback bug, lists fixed versions and recovery steps, and discusses testing and release-process improvements. ### Source excerpt How we broke auto-update in production and how we're addressing it. ## Delayed Start Compute Operations - Triggering Event DevFeed: [Delayed Start Compute Operations - Triggering Event]() Original publisher: [Read original article]() Author: Mihai Bojin Published: 2025-05-30T20:24:56Z Content type: article Language: en Sources: [Blog -- Neon Docs]() Topics: [Post Mortem](), [Databases](), [SQL](), [Serverless](), [Structured-data]() Tags: [2025](), [database](), [engineering](), [golang](), [ip](), [monitor](), [outage](), [performance](), [post-mortem](), [postgres](), [scale](), [serverless](), [serverless-architecture](), [sql]() ### AI overview This post-mortem summary explains how a Postgres query plan change in Neon's Activity Monitor caused database CPU saturation. The resulting slowdown prevented the control plane from suspending idle Compute VMs, increasing concurrent VMs and ultimately causing IP exhaustion during the 2025-05-16 outage. ### Source excerpt For further details, read the top-level Post-Mortem. Summary The Neon Control Plane service is backed by a Postgres database. A scheduled job in the Control plane, Activity Monitor, is responsible for identifying Computes that are ready to be suspended. A Postgres query executed... ## Our simple-to-use incident post-mortem template DevFeed: [Our simple-to-use incident post-mortem template]() Original publisher: [Read original article]() Author: Chris Evans Published: 2025-04-16T19:03:00Z Content type: article Language: en Sources: [The incident.io Blog]() Topics: [Post Mortem](), [Template](), [incident](), [Incident response](), [Vulnerabilities](), [data]() Tags: [article](), [data](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [metrics](), [outage](), [post-mortem](), [slack-incident](), [vulnerabilities]() ### AI overview This article presents an incident post-mortem template for documenting technical and other incidents. It explains how to combine incident data, human interpretation, metrics, and concrete follow-up actions to understand causes, learn from the response, and prevent similar incidents. ### Source excerpt Incident post-mortems are a crucial document that cannot be glossed over. In this article, you'll find our go-to post-mortem template that you can use in your own organization. ## Checkpoint - March 2025 DevFeed: [Checkpoint - March 2025]() Original publisher: [Read original article]() Author: Nixo Rokish Published: 2025-03-25T00:00:00Z Content type: news Language: en Sources: [Ethereum Foundation Blog]() Topics: [Ethereum](), [Development](), [incident](), [Post Mortem](), [configuration](), [Network]() Tags: [configuration](), [ethereum](), [feature](), [features](), [incident](), [network](), [post-mortem](), [research-development]() ### AI overview This checkpoint summarizes Ethereum core developers' recent work on the Pectra testnet upgrades and preparation for the Pectra mainnet fork. It covers configuration issues on the Holešky and Sepolia testnets, the launch of Hoodi for further testing, and conditions for selecting a mainnet activation date. ### Source excerpt Ethereum's weekly All Core Developer calls are a lot to keep up with, so this "Checkpoint" series aims for brief high-level updates with a target cadence of every 4-5 calls, depending on what's happening in core development. See the initial update here. All subsequent updates will be hosted here on... ## Where does the time go after you resolve an incident? DevFeed: [Where does the time go after you resolve an incident?]() Original publisher: [Read original article]() Author: Eryn Carman Published: 2024-07-29T20:51:00Z Content type: article Language: en Sources: [The incident.io Blog]() Topics: [incident](), [Incident response](), [Post Mortem]() Tags: [incident](), [incident-channel](), [incident-management](), [incident-response](), [outage](), [post-mortem](), [slack-incident](), [technical]() ### AI overview An analysis of 13,000 incidents and 14,000 follow-up action items finds that the median time to complete post-incident follow-ups is seven days. Smaller companies tend to finish faster, while medium-sized companies are slowest, largely because of coordination and process challenges. ### Source excerpt We were curious: where does the time go after an incident is resolved? To find out, we analyzed the post-incident process of 13,000 incidents and 14,000 follow-ups action items. ## Running better incidents from start to finish with Viktor Stanchev of Anchorage Digital DevFeed: [Running better incidents from start to finish with Viktor Stanchev of Anchorage Digital]() Original publisher: [Read original article]() Published: 2024-04-29T20:30:37Z Content type: article Language: en Sources: [The incident.io Blog]() Topics: [Incident response](), [incident](), [incident management](), [Post Mortem]() Tags: [incident](), [incident-channel](), [incident-management](), [incident-response](), [outage](), [post-mortem](), [slack-incident]() ### AI overview An episode of The Debrief features Viktor Stanchev of Anchorage Digital discussing practical ways to improve incident response. The conversation covers incident declaration, communication during incidents, and post-mortems, with advice intended for both experienced and newer teams. ### Source excerpt In this episode of The Debrief, we sit down with Viktor Stanchev of Anchorage Digital to get some actionable advice for running better incidents. ## Post-incident flows: Bringing consistency to your post incident processes DevFeed: [Post-incident flows: Bringing consistency to your post incident processes]() Original publisher: [Read original article]() Author: Luis Gonzalez Published: 2023-10-16T12:51:41Z Content type: article Language: en Sources: [The incident.io Blog]() Topics: [incident](), [Incident response](), [Post Mortem](), [Resilience]() Tags: [bug](), [building](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [learning](), [outage](), [post](), [post-mortem](), [resilience](), [slack-incident](), [writing]() ### AI overview The article introduces Post-incident Flows, a configurable checklist-based process for standardizing post-incident work. Teams can define tasks such as documenting timelines and summaries, tagging incidents, writing post-mortems, scheduling debriefs, and creating follow-up actions. The goal is to improve learning, communication, and resilience after incidents. ### Source excerpt With Post-incident flows, you can create a checklist of tasks and actions to ensure consistency across your teams and facilitate deeper learning. ## A guide to post-mortem meetings and how we run them at incident.io DevFeed: [A guide to post-mortem meetings and how we run them at incident.io]() Original publisher: [Read original article]() Author: incident.io Published: 2023-10-11T13:45:05Z Content type: tutorial Language: en Sources: [The incident.io Blog]() Topics: [Post Mortem](), [incident](), [Incident response](), [Learning]() Tags: [best-practices](), [culture](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [learning](), [outage](), [post-mortem](), [slack-incident]() ### AI overview This guide explains how to prepare for, run, and follow up on post-mortem meetings after incidents. It emphasizes structured discussion, blamelessness, open participation, and addressing contributing factors and impacts to support long-term improvement. ### Source excerpt Post-mortem meetings can play a crucial role in fostering an environment of continuous learning. Here's how we do them! ## Whose fault was it anyway? On blameless post-mortems DevFeed: [Whose fault was it anyway? On blameless post-mortems]() Original publisher: [Read original article]() Author: incident.io Published: 2023-10-04T19:54:46Z Content type: article Language: en Sources: [The incident.io Blog]() Topics: [Post Mortem](), [incident](), [incident management](), [Artificial Intelligence]() Tags: [analysis](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [learning](), [management](), [outage](), [post](), [post-mortem](), [production](), [root-cause-analysis](), [safety](), [slack-incident]() ### AI overview The article examines blameless post-mortems, arguing that incident analysis should avoid scapegoating while still preserving accountability and enabling meaningful learning. It discusses psychological safety, the limits of focusing on a single root cause, and the risk that AI-generated summaries may remove human accountability entirely. ### Source excerpt While blameless post-mortems are a great idea on the surface, if taken to the extreme, they can muddy how much you actually learn from incidents. ## Better learning from incidents: A guide to incident post-mortem documents DevFeed: [Better learning from incidents: A guide to incident post-mortem documents]() Original publisher: [Read original article]() Author: Luis Gonzalez Published: 2023-09-27T18:45:18Z Content type: article Language: en Sources: [The incident.io Blog]() Topics: [Post Mortem](), [incident](), [Incident response]() Tags: [guide](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [learning](), [outage](), [post-mortem](), [report](), [retrospective](), [slack-incident]() ### AI overview This guide explains post-mortem documents as a way to capture information after an incident, understand contributing factors and risks, and plan actions to prevent or reduce the impact of similar incidents. It distinguishes documents from post-mortem meetings, discusses disagreement about when they are appropriate, and describes blameless post-mortems as an approach that avoids scapegoating. The article also notes alternative terms such as incident debrief documents, Incident Retrospectives, and After Action Reports. ### Source excerpt Post-mortem documents are a great way to facilitate learning after incidents are resolved. ## Reflecting on one of the biggest incidents in our history DevFeed: [Reflecting on one of the biggest incidents in our history]() Original publisher: [Read original article]() Author: Luis Gonzalez Published: 2023-05-01T00:00:00Z Content type: article Language: en Sources: [The incident.io Blog]() Topics: [incident](), [Post Mortem]() Tags: [conference](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [kubecon](), [outage](), [post-mortem](), [recognition](), [slack-incident](), [storage]() ### AI overview The article humorously presents running out of T-shirts during KubeCon as a major incident. It recounts how unexpectedly high demand, amplified by recognition of the shirts as standout conference swag, quickly exhausted the team's supply. ### Source excerpt During KubeCon, we experienced a significant incident and rallied to resolve it. Here's the story behind it. ## Keep the monolith, but split the workloads DevFeed: [Keep the monolith, but split the workloads]() Original publisher: [Read original article]() Author: Lawrence Jones Published: 2023-04-12T00:00:00Z Content type: article Language: en Sources: [The incident.io Blog]() Topics: [Architecture & Design](), [Scalability](), [Microservices](), [Deployment](), [incident](), [Heroku](), [Post Mortem](), [Ruby](), [Database]() Tags: [architecture](), [deployment](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [microservices](), [observability](), [outage](), [post-mortem](), [ruby](), [scalability](), [slack-incident](), [systems]() ### AI overview The article argues that teams can preserve the simplicity of a monolith while addressing scaling problems by splitting workloads into separate deployment tiers. Drawing on an outage caused by repeated application crashes, it contrasts this approach with microservices, which can improve reliability and scalability but introduce distributed-system and operational complexity. The described implementation used three independent Heroku dyno tiers, each handling a distinct workload. ### Source excerpt Everybody loves a monolith, but you can hit issues as you scale. Learn how splitting workloads can improve your monolithic architecture's performance and scalability, and understand the trade-offs between monolithic systems and microservices. [Next page]()