{"id":4,"date":"2026-11-12T17:59:33","date_gmt":"2026-11-12T23:59:33","guid":{"rendered":"https:\/\/abcalpha.net\/blog\/caida-microsoft-365-health-checks-falla-cascada\/"},"modified":"2026-11-12T18:11:58","modified_gmt":"2026-11-13T00:11:58","slug":"caida-microsoft-365-health-checks-falla-cascada","status":"publish","type":"post","link":"https:\/\/abcalpha.net\/blog\/caida-microsoft-365-health-checks-falla-cascada\/","title":{"rendered":"Anatom\u00eda de la ca\u00edda de Microsoft 365 del 12 de noviembre: health checks, fallas en cascada y lo que revela un error de Outlook Web"},"content":{"rendered":"\r\n<p class=\"wp-block-paragraph\">El 12 de noviembre de 2026, Microsoft 365 sufri\u00f3 una de las ca\u00eddas m\u00e1s amplias del a\u00f1o. Durante horas, Exchange Online, Teams, SharePoint, Copilot y una lista creciente de servicios de seguridad y cumplimiento fallaron para usuarios de <strong>cualquier regi\u00f3n<\/strong>. Lo interesante desde el punto de vista de ingenier\u00eda es el mecanismo. Seg\u00fan Microsoft, <strong>no hubo m\u00e1s tr\u00e1fico del normal<\/strong>: los servidores empezaron a <strong>fallar sus revisiones autom\u00e1ticas de salud<\/strong> (<em>health checks<\/em>), salieron del servicio y dejaron al resto de la infraestructura con una carga que no pod\u00eda absorber.<\/p>\r\n\r\n\r\n\r\n<p class=\"wp-block-paragraph\">En este art\u00edculo reconstruimos la cronolog\u00eda t\u00e9cnica, analizamos el error que mostraba Outlook en la web y sacamos las lecciones de arquitectura que aplican a cualquier sistema que opere detr\u00e1s de un balanceador de carga.<\/p>\r\n\r\n\r\n\r\n<h2 class=\"wp-block-heading\">Resumen del incidente<\/h2>\r\n\r\n\r\n\r\n<figure class=\"wp-block-table\"><table><thead><tr><th>Identificador<\/th><th>Tipo<\/th><th>Alcance<\/th><th>Inicio (Guatemala \/ UTC)<\/th><\/tr><\/thead><tbody><tr><td>EX1550543<\/td><td>Incidente<\/td><td>Exchange Online: buzones inaccesibles desde Outlook en la web, MAPI, Exchange ActiveSync y la API REST<\/td><td>10:17 \/ 16:17<\/td><\/tr><tr><td>MO1550821<\/td><td>Aviso<\/td><td>Suite Microsoft 365: Teams, SharePoint Online, Copilot, Defender XDR, Planner, To Do, Intune, Defender for Office 365, Purview, Power BI, centro de administraci\u00f3n de Apps y Universal Print<\/td><td>12:26 \/ 18:26<\/td><\/tr><tr><td>TM1550488<\/td><td>Incidente (aparte)<\/td><td>Mensajer\u00eda de Teams en Am\u00e9rica, por contenci\u00f3n de recursos. Resuelto de 8:45 a 9:53<\/td><td>8:45 \/ 14:45<\/td><\/tr><\/tbody><\/table><\/figure>\r\n\r\n\r\n\r\n<p class=\"wp-block-paragraph\">TM1550488 fue un incidente distinto y anterior. No conviene mezclarlo con los otros dos en un an\u00e1lisis posterior.<\/p>\r\n\r\n\r\n\r\n<h2 class=\"wp-block-heading\">Cronolog\u00eda t\u00e9cnica<\/h2>\r\n\r\n\r\n\r\n<p class=\"wp-block-paragraph\">Horas de Guatemala (UTC\u22126), reconstruidas a partir de las actualizaciones p\u00fablicas de Microsoft 365 Status:<\/p>\r\n\r\n\r\n\r\n<figure class=\"wp-block-table\"><table><thead><tr><th>Hora<\/th><th>Evento<\/th><\/tr><\/thead><tbody><tr><td>10:17<\/td><td>Empieza EX1550543. Fallan las conexiones a los buzones por varios protocolos.<\/td><\/tr><tr><td>11:45<\/td><td>Microsoft encuentra errores de conectividad en la infraestructura que atiende las solicitudes de acceso y recopila registros de red.<\/td><\/tr><tr><td>12:07<\/td><td>El impacto puede alcanzar a usuarios de cualquier regi\u00f3n.<\/td><\/tr><tr><td>12:19<\/td><td>Hay carga elevada en varias regiones. Empiezan los reinicios y reparaciones.<\/td><\/tr><tr><td>12:43<\/td><td>Los servidores se vuelven intermitentemente no disponibles. Se redistribuye a nivel mundial el tr\u00e1fico de conexi\u00f3n de Outlook.<\/td><\/tr><tr><td>13:06<\/td><td>Se congelan <strong>todos<\/strong> los despliegues y cambios de configuraci\u00f3n.<\/td><\/tr><tr><td>13:18<\/td><td>La carga no viene de m\u00e1s tr\u00e1fico, sino de <strong>muchos servidores no disponibles de forma inesperada<\/strong>.<\/td><\/tr><tr><td>13:43<\/td><td>Los servidores fallan los <em>health checks<\/em> autom\u00e1ticos. Se sospecha de un cambio reciente en el componente que procesa esas revisiones.<\/td><\/tr><tr><td>13:57<\/td><td>No aparece ning\u00fan cambio que coincida con el inicio. Se omite el componente sospechoso en un subconjunto de servidores y se investiga un <strong>uso alto de procesador<\/strong>.<\/td><\/tr><tr><td>14:38<\/td><td>Muchos servidores dejan de responder durante la validaci\u00f3n y se reinician con el cambio aplicado.<\/td><\/tr><tr><td>14:56<\/td><td>Un <strong>m\u00e9todo alterno de health check<\/strong> devuelve un subconjunto de servidores al servicio. Se extiende al resto. Se preparan reinicios autom\u00e1ticos de los nodos que no respondan.<\/td><\/tr><tr><td>15:31\u201315:40<\/td><td>Se eval\u00faa revertir unas pocas actualizaciones de configuraci\u00f3n recientes.<\/td><\/tr><tr><td>16:00<\/td><td>Las acciones previas no dieron el alivio esperado: <strong>un proceso central de los servidores se satura<\/strong> y causa p\u00e9rdida de capacidad. Se a\u00edsla parte de la infraestructura para probar una recuperaci\u00f3n.<\/td><\/tr><tr><td>16:57<\/td><td>Una parte de los servidores vuelve y se mantiene estable. Se aplica gesti\u00f3n protectora de tr\u00e1fico. Hay recuperaci\u00f3n limitada.<\/td><\/tr><\/tbody><\/table><\/figure>\r\n\r\n\r\n\r\n<p class=\"wp-block-paragraph\">Al cierre de esta nota (18:30, hora de Guatemala), Microsoft no hab\u00eda publicado la causa ra\u00edz ni dado el incidente por resuelto. La p\u00e1gina p\u00fablica de estado de Microsoft <strong>tambi\u00e9n dej\u00f3 de cargar<\/strong> un rato, alrededor de las 13:21.<\/p>\r\n\r\n\r\n\r\n<h2 class=\"wp-block-heading\">\u00bfPor qu\u00e9 un health check puede tumbar un servicio entero?<\/h2>\r\n\r\n\r\n\r\n<p class=\"wp-block-paragraph\">Un balanceador de carga revisa peri\u00f3dicamente cada servidor de su grupo. Si un servidor no responde bien, lo saca de la rotaci\u00f3n para que los usuarios no lleguen a un nodo enfermo. Es un mecanismo de protecci\u00f3n, pero tiene un modo de falla conocido: la <strong>falla en cascada<\/strong>.<\/p>\r\n\r\n\r\n\r\n<ol class=\"wp-block-list\">\r\n<li>Por alguna raz\u00f3n, un grupo de servidores empieza a fallar la revisi\u00f3n. La causa puede ser un componente defectuoso, un pico de procesador o un cambio de configuraci\u00f3n.<\/li>\r\n\r\n\r\n\r\n<li>El balanceador los saca de la rotaci\u00f3n, y <strong>su tr\u00e1fico se reparte entre los que quedan<\/strong>.<\/li>\r\n\r\n\r\n\r\n<li>Los servidores restantes reciben m\u00e1s carga de la que pueden atender. Responden lento y <strong>tambi\u00e9n empiezan a fallar la revisi\u00f3n<\/strong>.<\/li>\r\n\r\n\r\n\r\n<li>Salen m\u00e1s servidores, la carga por nodo sube otra vez y el ciclo se repite.<\/li>\r\n\r\n\r\n\r\n<li>Cuando se reinician, los nodos que regresan reciben de golpe todas las conexiones pendientes y pueden caer de nuevo. Es una <strong>tormenta de reconexiones<\/strong>.<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n<p class=\"wp-block-paragraph\">Esto coincide con lo que Microsoft describi\u00f3: carga elevada sin aumento de tr\u00e1fico, servidores que fallaban la revisi\u00f3n y un proceso central saturado. Por eso la soluci\u00f3n tuvo que ver con <strong>cambiar la forma de revisar la salud<\/strong> y con <strong>automatizar los reinicios<\/strong>, no con agregar capacidad.<\/p>\r\n\r\n\r\n\r\n<h3 class=\"wp-block-heading\">El componente que revisa la salud tambi\u00e9n puede fallar<\/h3>\r\n\r\n\r\n\r\n<p class=\"wp-block-paragraph\">Si la revisi\u00f3n depende de un componente compartido, una falla en ese componente hace que <strong>servidores sanos parezcan enfermos<\/strong>. Ese componente puede ser un servicio de configuraci\u00f3n, un proceso que procesa las revisiones o una dependencia com\u00fan. Microsoft mencion\u00f3 justamente un \u00abcomponente responsable de procesar la salud de los servidores\u00bb. En ese escenario, el sistema de protecci\u00f3n se convierte en el origen de la ca\u00edda.<\/p>\r\n\r\n\r\n\r\n<h2 class=\"wp-block-heading\">Diseccionando el error de Outlook en la web<\/h2>\r\n\r\n\r\n\r\n<p class=\"wp-block-paragraph\">Este es el error que registramos en una de nuestras cuentas a las 17:45 (23:45 UTC), en plena ventana del incidente:<\/p>\r\n\r\n\r\n\r\n<pre class=\"wp-block-code\"><code>UTC Date: 2026-11-12T23:45:40.518Z\r\nClient Version: 20261030007.20\r\nBootResult: network\r\nerr: TypeError: Failed to fetch\r\nesrc: StartupData\r\net: ServerError\r\nestack: TypeError: Failed to fetch\r\n    at https:\/\/res.public.onecdn.static.microsoft\/owamail\/hashed-v1\/scripts\/owa.mailindex.fba3a5ca.js:2:148026\r\n    at new Promise (&lt;anonymous&gt;)<\/code><\/pre>\r\n\r\n\r\n\r\n<p class=\"wp-block-paragraph\">Cada campo cuenta parte de la historia:<\/p>\r\n\r\n\r\n\r\n<ul class=\"wp-block-list\">\r\n<li><strong><code>estack<\/code> apunta a <code>res.public.onecdn.static.microsoft<\/code>.<\/strong> El paquete de JavaScript de Outlook <strong>s\u00ed se descarg\u00f3<\/strong> desde la CDN de Microsoft y se ejecut\u00f3 en el navegador. La CDN de archivos est\u00e1ticos funcionaba.<\/li>\r\n\r\n\r\n\r\n<li><strong><code>esrc: StartupData<\/code>.<\/strong> Lo que fall\u00f3 fue la petici\u00f3n de <strong>datos de arranque<\/strong>: la primera llamada que hace la aplicaci\u00f3n al servidor de Outlook para obtener la configuraci\u00f3n del buz\u00f3n, las carpetas y la sesi\u00f3n. Sin esos datos, la aplicaci\u00f3n no puede dibujar la bandeja.<\/li>\r\n\r\n\r\n\r\n<li><strong><code>TypeError: Failed to fetch<\/code>.<\/strong> Es el error gen\u00e9rico de la API <code>fetch()<\/code> del navegador cuando <strong>no recibe ninguna respuesta HTTP utilizable<\/strong>. Puede venir de una conexi\u00f3n rechazada o reiniciada, de un tiempo de espera agotado, de un fallo de TLS o de una respuesta de error sin los encabezados que el navegador exige. Desde JavaScript no se puede distinguir entre esas causas.<\/li>\r\n\r\n\r\n\r\n<li><strong><code>BootResult: network<\/code> \/ <code>et: ServerError<\/code>.<\/strong> Outlook clasifica el arranque como fallido por red y atribuye el error al servidor.<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n<p class=\"wp-block-paragraph\"><strong>Conclusi\u00f3n:<\/strong> el cliente y la CDN estaban bien, y el <em>backend<\/em> que entrega los datos del buz\u00f3n no respond\u00eda. Es justo la capa que describe EX1550543.<\/p>\r\n\r\n\r\n\r\n<p class=\"wp-block-paragraph\">Un apunte de diagn\u00f3stico: el mismo mensaje puede aparecer por causas locales, como un proxy corporativo, una extensi\u00f3n del navegador que bloquea peticiones o una VPN. Para descartarlas basta con:<\/p>\r\n\r\n\r\n\r\n<ol class=\"wp-block-list\">\r\n<li>probar desde otra red, por ejemplo los datos m\u00f3viles;<\/li>\r\n\r\n\r\n\r\n<li>revisar la pesta\u00f1a <strong>Red<\/strong> de las herramientas de desarrollador y ver si la petici\u00f3n termina en <code>(failed)<\/code> o con un c\u00f3digo 5xx;<\/li>\r\n\r\n\r\n\r\n<li>comparar la hora con los incidentes abiertos en el estado del servicio.<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n<p class=\"wp-block-paragraph\">Si abres un ticket con Microsoft, el <strong>Client Id<\/strong> y el <strong>Session Id<\/strong> del error permiten rastrear la sesi\u00f3n.<\/p>\r\n\r\n\r\n\r\n<h2 class=\"wp-block-heading\">\u00bfC\u00f3mo debi\u00f3 reaccionar un equipo de TI?<\/h2>\r\n\r\n\r\n\r\n<h3 class=\"wp-block-heading\">Monitorear el estado sin depender de la consola<\/h3>\r\n\r\n\r\n\r\n<p class=\"wp-block-paragraph\">El centro de administraci\u00f3n y la p\u00e1gina de estado fallaron durante el incidente. Conviene consultar el estado del servicio por la <strong>API de Microsoft Graph<\/strong>, desde un script o una herramienta de monitoreo propia (requiere el permiso <code>ServiceHealth.Read.All<\/code>):<\/p>\r\n\r\n\r\n\r\n<pre class=\"wp-block-code\"><code>GET https:\/\/graph.microsoft.com\/v1.0\/admin\/serviceAnnouncement\/healthOverviews\r\nGET https:\/\/graph.microsoft.com\/v1.0\/admin\/serviceAnnouncement\/issues?$filter=isResolved eq false<\/code><\/pre>\r\n\r\n\r\n\r\n<p class=\"wp-block-paragraph\">Con eso se pueden mandar alertas a un canal que <strong>no dependa de Microsoft 365<\/strong>, por ejemplo SMS, Slack o un correo de otro proveedor.<\/p>\r\n\r\n\r\n\r\n<h3 class=\"wp-block-heading\">Configurar notificaciones fuera de Exchange<\/h3>\r\n\r\n\r\n\r\n<p class=\"wp-block-paragraph\">En <em>Service health \u2192 Manage notifications<\/em> se pueden registrar hasta dos direcciones. Si ambas est\u00e1n en Exchange Online, el aviso de que Exchange est\u00e1 ca\u00eddo <strong>nunca llega<\/strong>.<\/p>\r\n\r\n\r\n\r\n<h3 class=\"wp-block-heading\">Evitar acciones que empeoran el problema<\/h3>\r\n\r\n\r\n\r\n<p class=\"wp-block-paragraph\">Durante una ca\u00edda del proveedor, restablecer contrase\u00f1as, recrear perfiles de Outlook o quitar y volver a agregar cuentas no ayuda. Adem\u00e1s, genera trabajo y tickets cuando el servicio regresa.<\/p>\r\n\r\n\r\n\r\n<h3 class=\"wp-block-heading\">Entender c\u00f3mo se comporta el correo entrante<\/h3>\r\n\r\n\r\n\r\n<p class=\"wp-block-paragraph\">SMTP est\u00e1 dise\u00f1ado para reintentar. Seg\u00fan el RFC 5321, un servidor que no logra entregar un mensaje deber\u00eda seguir intent\u00e1ndolo durante <strong>al menos 4 a 5 d\u00edas<\/strong> antes de rendirse. Por eso, en una ca\u00edda de unas horas lo normal es que el correo llegue tarde, no que se pierda. El riesgo est\u00e1 en el correo <strong>saliente<\/strong> que el usuario cree haber enviado.<\/p>\r\n\r\n\r\n\r\n<h2 class=\"wp-block-heading\">Lecciones de arquitectura para nuestros propios sistemas<\/h2>\r\n\r\n\r\n\r\n<ol class=\"wp-block-list\">\r\n<li>**Separa <em>liveness<\/em> de <em>readiness<\/em>.** Un nodo lento pero vivo no siempre debe salir de la rotaci\u00f3n. Orquestadores como Kubernetes distinguen entre \u00abreiniciar el contenedor\u00bb y \u00abdejar de mandarle tr\u00e1fico\u00bb.<\/li>\r\n\r\n\r\n\r\n<li><strong>Usa revisiones de salud superficiales para el balanceo.<\/strong> Si el <em>health check<\/em> consulta la base de datos o un servicio compartido, una falla en esa dependencia saca a <strong>todos<\/strong> los nodos a la vez.<\/li>\r\n\r\n\r\n\r\n<li>**Ten un umbral de p\u00e1nico (<em>fail open<\/em>).** Si demasiados nodos fallan a la vez, lo m\u00e1s probable es que el problema est\u00e9 en la revisi\u00f3n. Envoy, por ejemplo, deja de excluir nodos cuando el porcentaje de sanos baja de un umbral configurable (50 % por defecto). AWS Application Load Balancer env\u00eda tr\u00e1fico a todos los destinos cuando todos aparecen no saludables.<\/li>\r\n\r\n\r\n\r\n<li>**Reinicia con escalonamiento y <em>jitter<\/em>.** Volver a meter todos los nodos a la vez provoca una tormenta de reconexiones. Hay que reincorporarlos de forma gradual.<\/li>\r\n\r\n\r\n\r\n<li><strong>Congela los cambios durante un incidente.<\/strong> Microsoft paus\u00f3 todos los despliegues en la primera hora. Es una pr\u00e1ctica que todo equipo deber\u00eda tener por escrito.<\/li>\r\n\r\n\r\n\r\n<li><strong>Aloja la p\u00e1gina de estado fuera de tu infraestructura.<\/strong> Si tu p\u00e1gina de estado cae junto con tu servicio, tus clientes se quedan sin informaci\u00f3n justo cuando m\u00e1s la necesitan.<\/li>\r\n\r\n\r\n\r\n<li><strong>Mide desde afuera.<\/strong> Un monitoreo externo independiente detecta la ca\u00edda tal como la ve el usuario, aunque los tableros internos digan que todo est\u00e1 bien.<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n<p class=\"wp-block-paragraph\">En ABC Alpha aplicamos estas pr\u00e1cticas en los sistemas que desarrollamos y operamos: monitoreo externo independiente, reinicios autom\u00e1ticos controlados y procedimientos de continuidad. Si tu organizaci\u00f3n depende de Microsoft 365 o de servicios en la nube cr\u00edticos, podemos ayudarte a dise\u00f1ar el monitoreo y el plan de contingencia.<\/p>\r\n\r\n\r\n\r\n<h2 class=\"wp-block-heading\">Fuentes<\/h2>\r\n\r\n\r\n\r\n<ul class=\"wp-block-list\">\r\n<li><a href=\"https:\/\/x.com\/MSFT365Status\/status\/2121016338181161457\">Microsoft 365 Status en X: actualizaci\u00f3n sobre servidores devueltos al servicio<\/a><\/li>\r\n\r\n\r\n\r\n<li><a href=\"https:\/\/x.com\/MSFT365Status\/status\/2121002505911857577\">Microsoft 365 Status en X: el proceso central saturado<\/a><\/li>\r\n\r\n\r\n\r\n<li><a href=\"https:\/\/x.com\/MSFT365Status\/status\/2120985048337830246\">Microsoft 365 Status en X: m\u00e9todo alterno de health check<\/a><\/li>\r\n\r\n\r\n\r\n<li><a href=\"https:\/\/statusstack.com\/blog\/microsoft-365-exchange-online-outage-november-12-2026\" target=\"_blank\" rel=\"noopener\">StatusStack: cronolog\u00eda de EX1550543 y MO1550821<\/a><\/li>\r\n\r\n\r\n\r\n<li><a href=\"https:\/\/windowsforum.com\/news\/exchange-online-ex1550543-mailbox-connectivity-recovery-status-and-admin-guidance.452081\/\" target=\"_blank\" rel=\"noopener\">Windows Forum: EX1550543, estado y gu\u00eda para administradores<\/a><\/li>\r\n\r\n\r\n\r\n<li><a href=\"https:\/\/www.xda-developers.com\/microsoft-suffering-major-outage-taking-down-microsoft-365-outlook-teams-onedrive\/\" target=\"_blank\" rel=\"noopener\">XDA Developers: cobertura del incidente<\/a><\/li>\r\n\r\n\r\n\r\n<li><a href=\"https:\/\/learn.microsoft.com\/en-us\/graph\/api\/resources\/service-communications-api-overview\" target=\"_blank\" rel=\"noopener\">Microsoft Learn: API de estado del servicio en Microsoft Graph<\/a><\/li>\r\n\r\n\r\n\r\n<li><a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc5321#section-4.5.4.1\" target=\"_blank\" rel=\"noopener\">RFC 5321, secci\u00f3n 4.5.4.1: estrategia de reintentos de SMTP<\/a><\/li>\r\n\r\n\r\n\r\n<li><a href=\"https:\/\/www.envoyproxy.io\/docs\/envoy\/latest\/intro\/arch_overview\/upstream\/load_balancing\/panic_threshold\" target=\"_blank\" rel=\"noopener\">Envoy: umbral de p\u00e1nico del balanceador<\/a><\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n<p class=\"wp-block-paragraph\"><em>Art\u00edculo actualizado el 12 de noviembre de 2026 a las 18:30 (hora de Guatemala). El incidente segu\u00eda abierto al momento de publicar.<\/em><\/p>\r\n\r\n","protected":false},"excerpt":{"rendered":"<p>Microsoft 365 cay\u00f3 sin un aumento de tr\u00e1fico: sus servidores empezaron a fallar las revisiones de salud y la carga se volvi\u00f3 una cascada. Cronolog\u00eda t\u00e9cnica, an\u00e1lisis del error de OWA y lecciones de arquitectura.<\/p>\n","protected":false},"author":4,"featured_media":5,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,2],"tags":[10,11,8,9,7],"class_list":["post-4","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-analisis-de-incidentes","category-infraestructura-nube","tag-balanceo-de-carga","tag-continuidad-del-negocio","tag-exchange-online","tag-health-checks","tag-microsoft-365"],"_links":{"self":[{"href":"https:\/\/abcalpha.net\/blog\/wp-json\/wp\/v2\/posts\/4","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abcalpha.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abcalpha.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abcalpha.net\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/abcalpha.net\/blog\/wp-json\/wp\/v2\/comments?post=4"}],"version-history":[{"count":1,"href":"https:\/\/abcalpha.net\/blog\/wp-json\/wp\/v2\/posts\/4\/revisions"}],"predecessor-version":[{"id":6,"href":"https:\/\/abcalpha.net\/blog\/wp-json\/wp\/v2\/posts\/4\/revisions\/6"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abcalpha.net\/blog\/wp-json\/wp\/v2\/media\/5"}],"wp:attachment":[{"href":"https:\/\/abcalpha.net\/blog\/wp-json\/wp\/v2\/media?parent=4"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abcalpha.net\/blog\/wp-json\/wp\/v2\/categories?post=4"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abcalpha.net\/blog\/wp-json\/wp\/v2\/tags?post=4"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}