Historial de interrupciones de Shiphawk

1. 2 de septiembre de 2026 a las 16:24 UTCmonitoring

   Los servicios web de FedEx están experimentando un rendimiento degradado, y algunos clientes han reportado problemas reservando envíos FedEx. Seguiremos vigilando la situación mientras FedEx trabaja para resolver el problema. Los tiempos de respuesta actuales de FedEx están disponibles aquí: https://www.shippingapimonitor.com/history.html?api=fedex

2. 2 de septiembre de 2026 a las 21:59 UTCresolved

   Resolvido en el lado FedEx.

Traducido automáticamente desde la actualización oficial del incidente.

1. 25 de agosto de 2026 a las 14:10 UTCinvestigating

   Algunos clientes están experimentando lentitud con el acceso WMS. Nuestro equipo está investigando activamente el tema.

2. 25 de agosto de 2026 a las 16:01 UTCmonitoring

   Se ha aplicado una solución y estamos monitoreando los resultados.

3. 25 de agosto de 2026 a las 17:40 UTCresolved

   Este incidente ha sido resuelto. Compartiremos más detalles tan pronto como estén disponibles.

4. 27 de agosto de 2026 a las 22:21 UTCpostmortem

   ## Post-Incident Report: WMS Slowness and Errors for Warehouses on One Database Instance - August 25, 2026 **Status:** Resolved **Ventana de incidentes:** 25 de agosto de 2026, ~04:30 - 08:45 PDT \(07:30 - 11:45 ET\) **Afectados:** Clientes cuyas bases de datos están alojadas en una instancia de base de datos WMS en nuestro grupo de almacén de EE.UU.-Este: tiempos de carga de página de hasta 20x normales, y errores intermitentes en pantallas de escáner y administración durante el peor período. **No afecta:** Todas las demás instancias de base de datos y grupos de almacén, la plataforma TMS, integridad de datos \(no se perdió, se duplicó o se aplicó parcialmente\), y todo el trabajo completado - cada transacción que fue aceptada fue procesada correctamente. ### ¿Te afectaste? El impacto se limitó a clientes cuyas bases de datos WMS están alojadas en una instancia de base específica en nuestro grupo de almacén de EE.UU.-Este, y sólo durante la mañana del 25 de agosto \(aproximadamente 04:30 - 08:45 PDT / 07:30 - 11:45 ET\). Si no vio cargas de página lentas en el WMS durante esa ventana, su entorno no estaba involucrado. Todas las demás instancias de base de datos y grupos de almacén, y toda la plataforma TMS, funcionaban normalmente en todas partes. #### Summary En la noche del 24 de agosto, un servicio de ETL de terceros que copia datos de ShipHawk en nuestro almacén de datos reiniciaron un amplio lote de sus trabajos de sincronización inmediatamente contra una de nuestras bases de datos de producción. Cada trabajo reiniciado comenzó a releer un atraso de los datos del cambio histórico a toda velocidad, en paralelo y sin ningún tipo de limitación. El volumen de lectura subió a aproximadamente cinco veces el pico esperado y consumió la mayor parte del ancho de banda del disco disponible para esa instancia de base de datos. Esto comenzó de la noche a la mañana, cuando la actividad de almacén es ligera, por lo que no tuvo efecto en las operaciones en ese momento. Cuando los turnos de la mañana del este de Estados Unidos comenzaron el 25 de agosto, la actividad normal de WMS se agregó en la parte superior del canal ya saturado y la instancia alcanzó su límite de ancho de banda. Desde el punto de vista de la aplicación esto apareció como respuestas lentas de la base de datos: las consultas que normalmente regresan en milisegundos tardaron mucho más, el trabajo colado detrás de ellos, y las páginas cargadas lentamente. Cuando una respuesta de la base de datos superó el tiempo de la aplicación, la página devolvió un error en lugar de cargar. El servicio siguió funcionando en todo el mundo. A través de la instancia afectada, los clientes procesaron aproximadamente el 70% del volumen normalmente manejado en esa ventana \(picks, packs y movimientos de inventario\), aunque la experiencia fue lenta y a veces difícil de trabajar con, y el grado de impacto variado entre los clientes. La situación se resolvió revocando las credenciales de la base de datos de servicios de ETL enteramente a las 08:37 PDT. La base de datos se recuperó en ocho minutos. El trabajo retrasado se desplazó durante las dos horas siguientes, y todos los almacenes afectados volvieron a su ritmo normal. Ninguna acción del cliente fue o es necesaria, y ningún dato fue afectado. No se perdió ninguna transacción, se duplicó o se aplicó parcialmente - comprobamos esto contra registros de integración que cubren la ventana del incidente completo. Trabajo que se presentó correctamente o falló limpiamente antes de realizar cualquier cambio. Esto está cubierto con más detalle a continuación. ### What was affected El impacto se limitó a clientes cuyas bases de datos están alojadas en la instancia de base de datos WMS afectada en el grupo de almacenes de Estados Unidos-Este. A lo largo de la ventana del incidente el sistema fue lento a través de la tabla - escáner y páginas de administración que normalmente cargan bien bajo un segundo tomó muchas veces más tiempo - y cuando una respuesta de la base superó el tiempo de aplicación, la página devolvió un error en lugar de cargar. Lo que esto parecía en la práctica: **Plano de casa:** páginas de escáner \(picking, moving, ajustando inventario\) cargadas muy lentamente; un trabajador que retridió mientras una página estaba atascada podría recibir una página de error y tener que volver y repetir la acción. **Los espejos se concentraron en una sola explosión en lugar de extenderse a través del incidente.** La mayoría de ellos cayeron dentro de una ventana de 15 minutos en el pico de la congestión \(06:15 - 06:30 PDT\). Contando páginas de error confirmadas en nuestro servidor web y registros de aplicaciones, el almacén más afectado vio 71 en esa ventana. **El sistema permaneció en todas partes.** Cada transacción presentada se completó correctamente o falló limpiamente antes de hacer cualquier cambio. Durante la ventana de desaceleración más profunda podemos mostrar cientos de transacciones completando con éxito para los usuarios que continuaron trabajando. ### What was NOT affected Integridad de datos** Los errores ocurrieron al comienzo mismo del proceso de solicitud, antes de que se hiciera cualquier cambio. No se perdió ninguna transacción, se duplicó o se aplicó parcialmente. Cada cumplimiento, movimiento de inventario, y envío de correos que lo completó correctamente - verificamos los registros de integración para la ventana del incidente. ** Sincronización de pedidos y envíos a ERPs y marketplaces** completados correctamente a lo largo de todo; las publicaciones que surgieron durante la desaceleración se entregaron en su totalidad durante la captura \(verificado en registros de integración - no publicaciones fallidas\). **Todos los demás ambientes.** Almacenes en nuestras otras instancias de bases de datos, y toda la plataforma TMS, funcionaron normalmente. Seguridad y tenencia. Ningún límite de seguridad estaba involucrado en ningún momento. El servicio de terceros en cuestión es un proveedor de integración de datos que opera bajo credenciales emitidas; la cuestión fue el volumen de sus lecturas, no cualquier acceso no autorizado. ### Timeline \(todas las veces PDT; add 3 hours for ET\) TENIDO TERRITORIO TERRITORIO TERRITORIO Silencio... Silencio Aug 24, 22:54 - 22:57 Silencio El servicio ETL reinicia ~22 trabajos de sincronización contra la base de datos en una ventana de tres minutos. Cada uno comienza a releer los datos del cambio histórico a toda velocidad. Silencio Aug 24, 22:54 - 23:50 Silencio Leer volumen escala aproximadamente cinco veces el pico esperado, consumiendo la mayor parte del ancho de banda del disco disponible para la instancia. El tráfico de almacén durante la noche es ligero, por lo que no hay ningún efecto visible para el cliente todavía. Silencio Aug 25, ~04:30 Silencio US-Este de los cambios de la mañana de almacén comienzan. La demanda combinada supera la velocidad de red tapada; las colas comienzan a construir y las primeras páginas comienzan a hacer que sea más lento de lo normal. Silencio 05:30 Silencio Alertas automáticas de monitoreo de tiempo de respuesta a medida que la actividad de almacén aumenta; informes de clientes de lentitud llegan en el mismo período. Comienza la investigación. Silencio 06:00 - 07:00 Silencio Congestión de pico: las conexiones de la base de datos aumentan a ~15x normal a medida que las solicitudes se acumulan; la ola de errores de la pantalla del escáner se produce \(06:15-06:30\). Silencio TEN 06:50 TENIDO Causa raíz identificada: ancho de banda de disco sobre el límite de instancia; los flujos de replicación del vendedor identificados como el conductor. TEN TEN 07:00 TENIDO El informe interno más pesado pregunta sobre las personas discapacitadas a la capacidad libre - alivio parcial. TEN 07:20 - 08:30 TENCIÓN Los trabajos de sincronización de servicios de ETL se detienen en ondas en su consola y sus sesiones de base de datos terminan; el servicio se conecta automáticamente en segundos cada vez y continúa leyendo. Durante este período comienzan trabajos adicionales. Silencio Silencio 08:35 Silencio Las credenciales de la base de datos de servicios de ETL están bloqueadas y sus sesiones terminaron una última vez. Silencio 08:38 - 08:45 Silencio Base de datos colas drenaje; los tiempos de respuesta de la página vuelven a la normalidad. El impacto del cliente termina. ### Why resolution took ~3 hours from first reports Tres factores ampliaron el plazo. Primero, el gatillo ocurrió siete horas antes de los síntomas. La releída del servicio ETL corrió durante toda la noche y ya había consumido el ancho de banda disponible, pero con luz de actividad de almacén a esa hora la restricción produjo sólo un ligero cambio en los tiempos de respuesta del sistema - por debajo de nuestros umbrales de alerta - por lo que no fue detectado. Nuestro monitoreo automatizado alertó una vez que la actividad del almacén se desplegó por la mañana, pero para entonces el cambio subyacente era de siete horas y no hubo cambios recientes de implementación o configuración a punto. En segundo lugar, la replicación del servicio de ETL es invisible a los registros estándar de consultas de bases de datos - utilizan un protocolo de replicación en lugar de consultas - así que identificarlos como el consumidor requerido correlacionar disco, red y evidencia de conexión. En tercer lugar, el servicio ETL se construye para sobrevivir interrupciones: pausing its jobs and terminating its connections both failed as mitigations because it reconnects automatically within seconds, and it restarted additional jobs while we were pausing others. Sólo revocar sus credenciales lo detuvo. ## Lo que estamos cambiando **Fortalecer los umbrales de alerta de WMS.** La condición detrás de este incidente estuvo presente durante siete horas por la noche, pero bajo carga ligera movió tiempos de respuesta demasiado poco para cruzar nuestros umbrales de alerta - por lo que la primera alerta vino sólo una vez que la actividad del almacén se desencadenó y los clientes ya se vieron afectados. Estamos sintonizando esos umbrales para ser sensibles a los cambios más pequeños en el tiempo de respuesta de WMS, incluyendo a baja carga, por lo que eventos como este son atrapados y actuados antes de que lleguen a los clientes. Esto incluye alertar sobre los indicadores principales específicos de este incidente - consumo de ancho de banda de disco y profundidad de cola de disco. **La base de datos ha sido migrada a un tipo de instancia con sustancialmente más ancho de banda de disco**, dando un importante espacio por encima de la demanda máxima para absorber picos de este tipo. ** Continuamos nuestra investigación con el proveedor de ETL.** Tenemos un caso abierto con ellos buscando una explicación para el reinicio del trabajo simultáneo, y requiriendo límite de tarifas y gorros de concurrencia para releer las cuentas contra las fuentes del cliente. Ese trabajo continúa.

Traducido automáticamente desde la actualización oficial del incidente.

1. 20 de agosto de 2026 a las 14:06 UTCinvestigating

   Hemos recibido informes de que TMS WebPortal está devolviendo errores o no cargando para algunos clientes. Estamos investigando activamente el problema y proporcionaremos actualizaciones a medida que se disponga de más información.

2. 20 de agosto de 2026 a las 15:02 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

3. 20 de agosto de 2026 a las 15:16 UTCmonitoring

   Se ha aplicado una solución y estamos monitoreando los resultados.

4. 20 de agosto de 2026 a las 18:06 UTCresolved

   Este incidente ha sido resuelto.

5. 20 de agosto de 2026 a las 19:35 UTCpostmortem

   # Post-Incident Report: Elevated API and Login Errores - Agosto 20, 2026 **Status:** Resolved **Ventana de incidentes:** 20 de agosto de 2026, 06:31 - 08:11 PDT \(13:31 - 15:11 UTC\) **Afectado:** Solicitudes de ShipHawk API y dashboard en entornos de producción compartidos, más el servicio de inicio de sesión. El impacto fue parcial en lugar de una salida completa: aproximadamente el 25% del tráfico global de API en [shiphawk.com](http://shiphawk.com) falló durante su ventana afectada; las tasas de fracaso dentro de los entornos afectados oscilaron entre aproximadamente el 37% y el 48%, y aproximadamente el 41% de las solicitudes de acceso al servicio. **No afecta:** Nota de In-Cart \(y todas las solicitudes /api/v4/rates\), procesamiento de antecedentes \(todos los trabajos programados, escribir respaldos, webhooks, generación de etiquetas async, seguimiento y comunicaciones de transportista funcionaron normalmente\), integridad de datos. ## Summary En la mañana del 20 de agosto, una actualización de seguridad crítica del sistema operativo publicada por Ubuntu - y aplicada automáticamente por nuestro proceso de parche estándar - contenía un defecto en el componente del servidor web \(nginx\) que se encuentra frente a la aplicación ShipHawk. El paquete afectado se publicó el 19 de agosto como [USN-8563-3] (https://ubuntu.com/security/notices/USN-8563-3). Ubuntu confirmó que esta actualización introdujo una regresión y publicó [USN-8563-4] (https://ubuntu.com/security/notices/USN-8563-4) el mismo día, revertiendo el cambio problemático pendiente de investigación. Mientras la versión defectuosa estaba funcionando, la capa proxy corrompió la URL de muchas solicitudes entrantes antes de entregarlas a la aplicación. La aplicación no podía igualar las URL corruptas a cualquier punto final conocido y respondió **404 No encontrado**. Los fallos fueron rechazos inmediatos y limpios: ninguna solicitud fue procesada parcialmente, trazada a la cuenta equivocada, o perdida después de la aceptación. Nuestros servidores no todos descargan e instalan actualizaciones de seguridad del sistema operativo en el mismo momento; actualizan cheques y ventanas de instalación se estancan entre hosts. Como resultado, algunos servidores descargaron la construcción de nginx defectuoso antes de que Ubuntu publicara el paquete corregido, mientras que otros revisaron más tarde y descargaron la compilación corregida directamente. Sólo los servidores que ya habían descargado el paquete defectuoso se vieron afectados cuando su instalación programada corría. Es por eso que la cuestión parecía intermitente: las solicitudes de otro tipo podrían fallar o tener éxito dependiendo de qué servidor las manejara. Incluso en servidores que ejecutan el paquete nginx defectuoso, sólo un subconjunto de solicitudes falló. La regresión afectó reglas específicas nginx routing en lugar de toda la configuración proxy, por lo que muchos patrones de URL continuaron trabajando normalmente en un servidor afectado. El incidente fue resuelto completamente por 08:11 PDT después de que cada servidor afectado fue actualizado al paquete corregido y verificado saludable. Ninguna acción del cliente fue o es necesaria. ## What was affected Los números siguientes cuentan **sólo fallas causadas por este incidente**. Ordinary 404 responses \(lookups of records that genuinely don't exist, invalid URLs, bot traffic\) were identified by their distinct response signature and excluded. ← Medio ambiente Silencioso Silencioso ventana impactada \(PDT\) Silencio --- Silencio --- Silencio sh-p-1 ambiente TENIDO 2 de 3 servidores web TEN 06:34 - 08:08 TENED37% de las solicitudes en servidores afectados; ♥25% del tráfico global de API ANTE Silencio Inicio de sesión servicio Silencio Ambos servidores Silencio 06:33 - 08:08 Silencio 41% de las solicitudes de servicio Silencio Silencio sh-p-2 entorno TENIDO 2 de 3 servidores web TEN 06:31 - 08:08 Silencio 47% de las solicitudes en los servidores afectados tención sh-p-3 entorno TENIDO 2 de 3 servidores web TEN 06:31 - 08:11 TENED48% de las solicitudes en servidores afectados Lo que esto parecía en la práctica: * **Las integraciones de la API** recibieron respuestas HTTP 404 para solicitudes válidas. Debido a que los fallos eran inmediatos y apátridas, los registros de clientes podrían tener éxito cuando aterrizaron en un servidor no afectado. * **Dashboard and login** pages failed to load or sign in intermittently. * Los fracasos dependían de la URL exacta: algunos tipos de solicitud pasaron a través de servidores inapropiados, añadiendo a la apariencia intermitente. ## What was NOT affected * ** Solicitudes de calificación en coche.** Todas las solicitudes de calificación del portal web, las plataformas de comercio electrónico, las plataformas de planificación de los recursos institucionales y las solicitudes periódicas de API a " api/v4/rates " estaban funcionando como siempre. * **Los empleos de base no se vieron afectados en absoluto.** Todo el procesamiento asincrónico - trabajos programados, copias de seguridad, sincronización de inventario, entregas webhook, generación de documentos y etiquetas, transporte y comunicaciones ERP - corre detrás de la capa proxy y continuó normalmente durante todo el incidente. No se perdió ni se retrasó el trabajo. * * * Integridad de datos* No se perdieron, alteraron ni corrompieron datos. Las solicitudes se completaron normalmente o fueron rechazadas de manera directa. * Seguridad y tenencia.* No se envió ninguna solicitud a otra cuenta, y no se cruzó ningún límite de seguridad. The corruption occurred after all access controls were applied. La actualización Ubuntu subyacente fue un parche de seguridad preventiva; la vulnerabilidad que se trató no fue explotada en nuestros sistemas. ## Timeline \(todas las veces PDT, 20 de agosto, 2026\) * **Ago 19 \(daytime\)** - Ubuntu publica una actualización de seguridad para nginx; se reporta un defecto, y Ubuntu publica un paquete corregido el mismo día. La versión corregida se propaga a espejos de actualización pública durante la noche. * **Ago 19, 18:24 - 23:09** - La actualización nocturna verifica los servidores afectados más tarde descarga la actualización nginx del día. En estos momentos, la construcción defectuosa sigue siendo la más reciente disponible en los espejos. Este paso sólo descarga el paquete; la instalación ocurre durante la ventana de parche de la mañana siguiente. * **Ago 20, 04:12 - 05:05** - Otro grupo de servidores ejecuta su cheque de actualización nocturna después de que la construcción corregida ha alcanzado los espejos. Estos servidores descargan la versión fija y permanecen sanos durante todo el incidente. * **~06:00** - Se aplica una actualización de configuración de aplicación no relacionada de rutina para las próximas versiones. No tiene ningún efecto en la funcionalidad publicada actualmente y ** no juega ningún papel en el incidente**, pero debido a que es el único cambio conocido esa mañana, se convierte en el primer sospechoso una vez que aparecen errores. * **06:00** - La ventana de parche automatizada nocturna comienza a rodar actualizaciones nginx a través de entornos. Algunos servidores ya tienen el paquete corregido descargado, mientras que otros tienen el paquete defectuoso. * **06:31 - 06:34 - INCIDENT START.** A medida que avanza la ventana de parche automatizada, el paquete nginx defectuoso descargado previamente se instala en múltiples servidores web y de inicio de sesión en entornos de producción compartidos. Debido a que los horarios de parche están estancados, no todos los servidores actualizan a la vez, y algunos servidores permanecen saludables. Las primeras solicitudes fallidas de atención al cliente comienzan en **06:31**. * **06:35** - Alertas de monitorización externa automatizadas sobre errores elevados. **La investigación comienza inmediatamente.** * **06:36 - 07:15** - Los ingenieros primero investigan la actualización de configuración ~06:00, el único cambio de nivel de aplicación conocido con el tiempo de coincidencia estrecha. Se descarta, y la atención se convierte en la capa web/proxy. * **06:52** - La ventana de parche continua y el paquete defectuoso se activa en servidores adicionales. El impacto aumenta a medida que los servidores más afectados reinician en la versión nginx defectuosa, mientras que los servidores que descargaron el paquete corregido de Ubuntu siguen siendo saludables. * **06:55** - Una actualización del servidor web restante utilizando el paquete corregido de Ubuntu y permanece saludable a lo largo de todo, continuando sirviendo su parte del tráfico correctamente. * **07:18 - 07:19** - Los servidores web afectados se reinician como un intento de mitigación. Esto no tiene efecto porque el paquete nginx defectuoso permanece instalado. * **07:20 - 07:55** - Los servidores sospechosos se eliminan de la rotación del balanceador de carga. Los síntomas persisten porque el servicio de inicio de sesión y los entornos de aplicación se ven afectados independientemente, lo que amplía materialmente la búsqueda. * **07:41** - El patrón de corrupción URL se identifica en los registros de aplicaciones. * **07:45 - 08:00** - La prueba del servidor aísla los servidores defectuosos. La única diferencia de servidores saludables es la versión del paquete nginx. La construcción defectuosa se corresponde con el aviso de regresión publicado por Ubuntu y el paquete corregido. * **08:02 - 08:11** - El paquete corregido se instala en todos los servidores afectados. Los índices de error vuelven a la normalidad inmediatamente en cada servidor mientras se reinicia en la versión fija. El ambiente final afectado regresa a la normalidad en **08:11 - INCIDENT FULLY RESOLVED**. * **08:11\+** - Se completa la verificación completa: cada servidor se prueba individualmente, y API, dashboard, login y entornos de producción se confirman saludables. ## Why resolution took ~95 minutes from alert La detección fue rápida, pero tres factores retrasaron el diagnóstico. En primer lugar, un cambio de configuración de rutina a principios de la mañana fue el único cambio conocido en el medio ambiente y tuvo que descartarse - el parche automatizado del sistema operativo no aparece en ningún registro de cambio de nivel de aplicación. En segundo lugar, el fallo fue intermitente por naturaleza: los servidores no afectados continuaron sirviendo normalmente, e incluso los servidores afectados manejaron con éxito tipos de solicitud cuyos reglas de enrutamiento no se vieron afectados. En tercer lugar, la eliminación de los servidores sospechosos de la rotación no detuvo los errores - porque otros niveles fueron afectados independientemente - que inicialmente señaló la investigación lejos de esos servidores. ## What we are changing **1. Escenificación de los parches de seguridad del sistema operativo antes de la producción.** Las actualizaciones de seguridad automatizadas de nivel OS y nginx, incluidos los parches críticos, se instalarán primero en servidores no productivos. La validación de nivel de aplicación automatizada ejercerá API representativa, dashboard y las rutas de inicio de sesión contra los servidores actualizados antes de que se permita que las versiones del mismo paquete entren en producción. La producción se iniciará sólo después de que pasen esos cheques. **2. Diagnóstico de nivel de versión más rápido** Nuestros cuadernos de incidentes ahora incluyen la comparación inmediata de versiones de paquetes y la historia de reiniciar en servidores siempre que servidores idénticos configurados se comportan de manera diferente.

Traducido automáticamente desde la actualización oficial del incidente.

1. 26 de junio de 2026 a las 15:47 UTCmonitoring

   We are seeing a degraded performance with FedEx API, some customers reported issues with booking FedEx shipments. We are actively monitoring the situation and will provide updates as soon as more information becomes available or the issue is resolved.

2. 26 de junio de 2026 a las 20:49 UTCresolved

   Resolved by FedEx

1. 19 de junio de 2026 a las 15:38 UTCmonitoring

   We are seeing a degraded performance with USPS Endicia web services. We will continue to monitor as USPS Endicia works to resolve this. https://status.endicia.com

2. 20 de junio de 2026 a las 2:17 UTCresolved

   This incident has been resolved.

1. 18 de mayo de 2026 a las 18:21 UTCidentified

   PrintNode is currently experiencing issues. Some regions may be experiencing degraded performance when attempting to print. See https://www.printnode.com/en/status for details.

2. 18 de mayo de 2026 a las 21:43 UTCresolved

   Resolved by PrintNode.

1. 23 de febrero de 2026 a las 20:12 UTCidentified

   We are seeing a degraded performance with FedEx web services, some customers reported issues with booking shipments. FedEx has acknowledged an issue on their end. We are actively monitoring the situation and will provide updates as soon as more information becomes available or the issue is resolved.

2. 24 de febrero de 2026 a las 22:52 UTCresolved

   Resolved by FedEx.

1. 20 de octubre de 2025 a las 20:37 UTCinvestigating

   Amazon Web Services had a major outage today that effected a large number software services across the internet, including ShipHawk. While ShipHawk's software did not go down, the outage has led to intermittent reliability for many parcel and LTL carriers regarding rating and label generation. We are working with AWS to resolve these issues as soon as possible. https://health.aws.amazon.com/health/status

2. 20 de octubre de 2025 a las 20:56 UTCmonitoring

   Amazon Web Services had a major outage today that effected a large number software services across the internet, including ShipHawk. While ShipHawk's software did not go down, the outage has intermittently affected some carriers regarding rating and label generation. Everything is working currently and we are working with AWS to ensure system responsiveness. https://health.aws.amazon.com/health/status

3. 20 de octubre de 2025 a las 23:28 UTCresolved

   The AWS issue affecting carriers has been resolved.

1. 10 de octubre de 2025 a las 17:51 UTCinvestigating

   We are seeing a degraded performance with USPS Endicia web services. We will continue to monitor as USPS Endicia works to resolve this. https://status.endicia.com

2. 10 de octubre de 2025 a las 18:18 UTCresolved

   Resolved by USPS Endicia

1. 29 de septiembre de 2025 a las 18:05 UTCidentified

   Customers using WWEX / SpeedShip integrations may experience issues with rating and booking shipments due to an outage of the WWEX / SpeedShip API. The provider has notified us that they are actively working on a resolution. We will continue monitoring and provide updates as they become available.

2. 29 de septiembre de 2025 a las 22:40 UTCresolved

   Confirmed as resolved by WWEX.

1. 20 de junio de 2025 a las 13:30 UTCidentified

   PrintNode is currently experiencing connectivity issues. Some regions may be experiencing degraded performance when attempting to print. See https://www.printnode.com/en/status for details.

2. 20 de junio de 2025 a las 13:42 UTCidentified

   Connectivity was restored to normal approximately 7 minutes ago; we are monitoring the situation and will post further information if and when it becomes available.

3. 20 de junio de 2025 a las 17:21 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 21 de junio de 2025 a las 4:07 UTCresolved

   This incident has been resolved.

1. 5 de mayo de 2025 a las 17:27 UTCidentified

   Pitney Bowes has notified us they are experiencing technical issues with PB Expedited Delivery Services. Customers who use Pitney Bowes may experience slowness or unavailability of Pitney Bowes shipping rates or printing labels. We will continue to monitor their progress as they resolve this issue. For additional information use Pitney Bowes status page - https://status.pitneybowes.com

2. 6 de mayo de 2025 a las 23:10 UTCresolved

   This incident has been resolved.

1. 14 de abril de 2025 a las 20:24 UTCinvestigating

   We are currently investigating an issue affecting one of our WMS environments. A subset of customers may be unable to access the system. Our team is actively working to identify the root cause and restore full access as soon as possible. We will continue to provide updates as we make progress. Thank you for your understanding and patience.

2. 14 de abril de 2025 a las 20:34 UTCmonitoring

   The affected WMS environment is now back online, and system access has been restored for impacted customers. We are currently monitoring the environment to ensure stability.

3. 14 de abril de 2025 a las 20:47 UTCresolved

   This incident has been resolved.

1. 11 de marzo de 2025 a las 11:52 UTCinvestigating

   Some customers are experiencing slowness with the rating API. Our team is actively investigating the issue. We will provide updates as we learn more.

2. 11 de marzo de 2025 a las 12:00 UTCmonitoring

   The issue causing slowness in the rating API has been identified and resolved.

3. 11 de marzo de 2025 a las 22:34 UTCresolved

   This incident has been resolved.

1. 30 de enero de 2025 a las 13:42 UTCidentified

   Pitney Bowes has notified us they are experiencing technical issues with PB Expedited Delivery Services. Customers who use Pitney Bowes may experience slowness or unavailability of Pitney Bowes shipping rates or printing labels. We will continue to monitor their progress as they resolve this issue. For additional information use Pitney Bowes status page - https://status.pitneybowes.com

2. 30 de enero de 2025 a las 15:59 UTCresolved

   Resolved by Pitney Bowes

1. 25 de julio de 2024 a las 17:53 UTCidentified

   We are seeing a degraded performance with UPS web services. We will continue to monitor as UPS works to resolve this. To see current response times from UPS you can check: - https://downdetector.com/status/ups/ - https://www.shippingapimonitor.com/history.html?api=ups

2. 25 de julio de 2024 a las 20:00 UTCmonitoring

   UPS resolved the issue on their side, we will continue to monitor it.

3. 26 de julio de 2024 a las 0:14 UTCresolved

   This incident has been resolved.

1. 18 de junio de 2024 a las 17:03 UTCidentified

   USPS Endicia has noted that they have fixed the postage printing issue. See USPS Endicia status page for more details: https://status.endicia.com/

2. 18 de junio de 2024 a las 23:19 UTCresolved

   Resolved by Endicia.

1. 17 de junio de 2024 a las 16:01 UTCidentified

   We are seeing a degraded performance with FedEx web services. We will continue to monitor as FedEx works to resolve this. To see current response times from FedEx you can check: https://www.shippingapimonitor.com/history.html?api=fedex

2. 18 de junio de 2024 a las 17:01 UTCresolved

   Resolved by FedEx.

1. 22 de mayo de 2024 a las 17:46 UTCidentified

   We are seeing a degraded performance with FedEx web services. We will continue to monitor as FedEx works to resolve this. To see current response times from FedEx you can check: https://www.shippingapimonitor.com/history.html?api=fedex

2. 22 de mayo de 2024 a las 20:20 UTCresolved

   Resolved by FedEx team.

1. 17 de mayo de 2024 a las 19:18 UTCidentified

   We are seeing a degraded performance with UPS web services. We will continue to monitor as UPS works to resolve this. To see current response times from UPS you can check: - https://downdetector.com/status/ups/ - https://www.shippingapimonitor.com/history.html?api=ups

2. 17 de mayo de 2024 a las 22:41 UTCresolved

   Resolved by UPS.