Histórico de interrupções do Shiphawk

1. 2 Gwengolo 2026 da 16:24 UTCmonitoring

   Os serviços da Web FedEx estão atualmente experimentando desempenho degradado, e alguns clientes relataram problemas reservando remessas FedEx. Continuaremos a monitorar a situação enquanto o FedEx trabalha para resolver o problema. Os tempos de resposta atuais do FedEx estão disponíveis aqui: https://www.shippingapimonitor.com/history.html?api=fedex

2. 2 Gwengolo 2026 da 21:59 UTCresolved

   Resolvido do lado do FedEx.

Traduzido automaticamente da atualização oficial do incidente.

1. 25 Eost 2026 da 14:10 UTCinvestigating

   Alguns clientes estão experimentando lentidão com o acesso WMS. A nossa equipa está a investigar a questão.

2. 25 Eost 2026 da 16:01 UTCmonitoring

   Foi implementada uma correção e estamos monitorando os resultados.

3. 25 Eost 2026 da 17:40 UTCresolved

   Este incidente foi resolvido. Partilharemos mais detalhes assim que estiverem disponíveis.

4. 27 Eost 2026 da 22:21 UTCpostmortem

   # # Relatório pós-incidente: WMS lentidão e erros para Armazéns em uma instância de banco de dados - 25 de agosto de 2026 ** Status: ** Resolvido ** Janela incidente:** 25 de Agosto de 2026, ~04:30 - 08:45 PDT \(07:30 - 11:45 ET\) **Afetado:** Clientes cujos bancos de dados estão hospedados em uma instância de banco de dados WMS em nosso grupo de armazém EUA-East: tempos de carga de página de até 20x normal, e erros intermitentes em telas de scanner e administrador durante o pior período. ** Não afectado: ** Todas as outras instâncias de banco de dados WMS e grupos de armazéns, a plataforma TMS, integridade de dados \(nenhuma transação foi perdida, duplicada ou parcialmente aplicada\), e todo o trabalho concluído - cada transação que foi aceita foi processada corretamente. Foste afectado? O impacto foi limitado a clientes cujas bases de dados WMS estão hospedadas em uma instância de banco de dados específica em nosso grupo de armazém EUA-Leste, e apenas durante a manhã de 25 de agosto \(aproximadamente 04:30 - 08:45 PDT / 07:30 - 11:45 ET\). Se você não viu cargas lentas de página no WMS durante essa janela, seu ambiente não estava envolvido. Todas as outras instâncias de banco de dados WMS e grupos de armazéns, e toda a plataforma TMS, funcionaram normalmente em todo o lado. Resumo Na noite de 24 de agosto, um serviço de ETL de terceiros que copia dados ShipHawk em nosso data warehouse reiniciou um grande lote de seus trabalhos de sincronização ao mesmo tempo contra uma de nossas bases de dados de produção. Cada trabalho reiniciado começou a reler um backlog de dados históricos de mudança a toda velocidade, em paralelo e sem qualquer limitação de taxa. O volume de leitura subiu para aproximadamente cinco vezes o pico esperado e consumiu a maior parte da largura de banda de disco disponível para essa instância de banco de dados. Isto começou durante a noite, quando a atividade do armazém é leve, de modo que não teve efeito sobre as operações na época. Quando os turnos da manhã EUA-Leste começaram em 25 de agosto, a atividade normal do WMS foi adicionada no topo do canal já saturado e a instância atingiu seu limite de largura de banda. Do ponto de vista da aplicação isso apareceu como respostas lentas do banco de dados: consultas que normalmente retornam em milissegundos levaram muito mais tempo, trabalho em fila atrás deles, e páginas carregadas lentamente. Quando uma resposta de banco de dados excedeu o tempo limite da aplicação, a página devolveu um erro em vez de carregar. O serviço permaneceu operacional durante todo o período. Em toda a instância afetada, os clientes processaram aproximadamente 70% do volume normalmente manipulado nessa janela \(picks, pacotes e movimentos de inventário\), embora a experiência foi lenta e às vezes difícil de trabalhar com, e o grau de impacto variou entre os clientes. A situação resolvida pela revogação das credenciais da base de dados de serviços ETL inteiramente às 08:37 PDT. A base de dados foi recuperada em oito minutos. O trabalho atrasado passou por duas horas, e todos os armazéns afetados voltaram ao ritmo normal. Nenhuma ação do cliente foi ou é necessária, e nenhum dado foi afetado. Nenhuma transação foi perdida, duplicada ou parcialmente aplicada - nós verificamos isso contra registros de integração cobrindo a janela de incidente completo. Trabalho que foi submetido ou concluído corretamente ou falhou de forma limpa antes de fazer qualquer alteração. Isto está mais detalhado abaixo. O que foi afectado O impacto foi limitado aos clientes cujas bases de dados estão hospedadas na instância de banco de dados WMS afetada no grupo de armazéns EUA-Leste. Durante toda a janela incidente o sistema foi lento em todo o tabuleiro - scanner e páginas de administração que normalmente carregam em bem abaixo de um segundo levou muitas vezes mais tempo - e onde uma resposta de banco de dados excedeu o tempo de aplicação, a página retornou um erro em vez de carregar. O que isto parecia na prática: **Warehouse floor:** scan pages \(picking, movendo-se, ajustando inventário\) carregado muito lentamente; um trabalhador que tentou novamente enquanto uma página estava presa poderia receber uma página de erro e tem que voltar e repetir a ação. ** Os erros foram concentrados em uma única explosão em vez de se espalharem através do incidente. A maioria deles caiu dentro de uma janela de 15 minutos no pico do congestionamento \(06:15 - 06:30 PDT\). Contando páginas de erro confirmadas em nosso servidor web e registros de aplicativos, o armazém mais afetado viu 71 naquela janela. ** O sistema permaneceu em toda parte.** Cada transação enviada foi concluída corretamente ou falhou de forma limpa antes de fazer qualquer alteração. Durante a janela de desaceleração mais profunda, podemos mostrar centenas de transações completando com sucesso para os usuários que continuaram trabalhando. O que não foi afectado ** Integridade dos dados. Os erros ocorreram no início do processamento da solicitação, antes de qualquer alteração ser feita. Nenhuma transação foi perdida, duplicada ou parcialmente aplicada. Cada preenchimento, movimento de inventário e postagem de envio que completaram fez isso corretamente - nós verificamos os registros de integração para a janela incidente. ** Sincronização de pedidos e envios para ERPs e marketplaces** completados corretamente ao longo; as postagens que foram colocadas em fila durante o abrandamento foram entregues na íntegra durante o catch-up \(verificado em logs de integração - nenhuma postagem falhou\). ** Todos os outros ambientes. Armazéns em nossas outras instâncias de banco de dados, e toda a plataforma TMS, funcionavam normalmente. ** Segurança e arrendamento. Nenhum limite de segurança foi envolvido em qualquer momento. O serviço de terceiros em questão é um fornecedor de integração de dados que opera sob credenciais emitidas; o problema foi o volume de suas leituras, não qualquer acesso não autorizado. ## # Timeline \(all times PDT; add 3 horas para ET\) Tempo , Evento , --- --- --- --- O serviço ETL reinicia ~22 tarefas de sincronização contra o banco de dados dentro de uma janela de três minutos. Cada um começa a re-ler dados históricos de mudança em velocidade máxima. O volume de leitura sobe para aproximadamente cinco vezes o pico esperado, consumindo a maior parte da largura de banda do disco disponível para a instância. O tráfego do armazém overnight é leve, então não há nenhum efeito visível do cliente ainda. 25 de agosto, ~04:30 , os turnos da manhã do armazém EUA-Leste começam. A demanda combinada excede a velocidade da rede; as filas começam a construir e as primeiras páginas começam a ficar mais lentas do que o normal. 05:30 Alertas automáticos de monitoramento de tempo de resposta à medida que a atividade do armazém aumenta; os relatórios dos clientes de lentidão chegam no mesmo período. A investigação começa. □ 06:00 - 07:00 □ Congestão máxima: as conexões de banco de dados aumentam para ~15x normal à medida que os pedidos se acumulam; a onda de erros de scanner-tela ocorre \(06:15-06:30\). □ A causa raiz identificada: largura de banda do disco sobre o limite da instância; fluxos de replicação do fornecedor identificados como o driver. 07:00 Mais alto relatório interno consultas desactivadas para a capacidade livre - alívio parcial. 07:20 - 08:30 As tarefas de sincronização de serviço ETL são pausadas em ondas em seu console e suas sessões de banco de dados encerradas; o serviço reconecta automaticamente dentro de segundos cada vez e continua lendo. Durante este período começa trabalhos adicionais. □ As credenciais do banco de dados do serviço ETL estão bloqueadas e suas sessões terminaram uma última vez. As filas do banco de dados dreno; os tempos de resposta da página retornam ao normal. O impacto do cliente termina. # # # Por que a resolução levou ~3 horas dos primeiros relatórios Três fatores estenderam a linha do tempo. Primeiro, o gatilho ocorreu sete horas antes dos sintomas. A re-leitura do serviço ETL correu durante a noite e já tinha consumido a largura de banda disponível, mas com a luz de atividade do armazém naquela hora a restrição produziu apenas uma ligeira mudança nos tempos de resposta do sistema - abaixo dos nossos limiares de alerta - por isso não foi detectado. Nosso monitoramento automatizado alertou uma vez que a atividade do armazém aumentou de manhã, mas até então a mudança subjacente tinha sete horas e não havia nenhuma implantação recente ou mudança de configuração para apontar. Em segundo lugar, as leituras de replicação do serviço de ETL são invisíveis aos logs de consulta de banco de dados padrão - eles usam um protocolo de replicação em vez de consultas - para identificá-los como o consumidor necessário correlacionando disco, rede e evidência de nível de conexão. Em terceiro lugar, o serviço ETL é construído para sobreviver às interrupções: pausar seus trabalhos e terminar suas conexões falhou tanto como mitigação porque ele reconecta automaticamente em segundos, e ele reiniciou trabalhos adicionais enquanto nós estávamos pausando outros. Só a revogação das suas credenciais o impediu. O que estamos a mudar ** Limiares de alerta de tempo de resposta WMS. ** A condição por trás deste incidente esteve presente durante sete horas durante a noite, mas sob carga leve moveu tempos de resposta muito pouco para cruzar nossos limiares de alerta - então o primeiro alerta veio apenas uma vez que a atividade armazém aumentou e os clientes já foram afetados. Estamos ajustando esses limiares para sermos sensíveis a turnos menores no tempo de resposta WMS, inclusive em baixa carga, então eventos como este são capturados e agidos antes que eles cheguem aos clientes. Isto inclui alerta sobre os indicadores principais específicos deste incidente - consumo de largura de banda de disco e profundidade de fila de disco. **O banco de dados foi migrado para um tipo de instância com substancialmente mais largura de banda do disco**, dando significativa headroom acima da demanda de pico para absorver picos deste tipo. ** Estamos continuando nossa investigação com o fornecedor de ETL.** Temos um caso aberto com eles buscando uma explicação para o reinício simultâneo do trabalho, e exigindo limites de taxa e concorrência para re-leituras contra fontes de clientes. Esse trabalho está em curso.

Traduzido automaticamente da atualização oficial do incidente.

1. 20 Eost 2026 da 14:06 UTCinvestigating

   Recebemos relatórios de que o TMS WebPortal está retornando erros ou falhando em carregar para alguns clientes. Estamos investigando ativamente o problema e forneceremos atualizações à medida que mais informações ficam disponíveis.

2. 20 Eost 2026 da 15:02 UTCidentified

   A questão foi identificada e está a ser implementada uma solução.

3. 20 Eost 2026 da 15:16 UTCmonitoring

   Foi implementada uma correção e estamos monitorando os resultados.

4. 20 Eost 2026 da 18:06 UTCresolved

   Este incidente foi resolvido.

5. 20 Eost 2026 da 19:35 UTCpostmortem

   # Relatório Pós-Incidente: Erros de API e de login elevados - 20 de agosto de 2026 ** Status: ** Resolvido ** Janela incidente:** 20 de agosto de 2026, 06:31 - 08:11 PDT \(13:31 - 15:11 UTC\) **Afetado:** Pedidos de API e painel ShipHawk em ambientes de produção compartilhados, além do serviço de login. O impacto foi parcial em vez de uma falha completa: aproximadamente 25% do tráfego total da API em [shiphawk.com](http://shiphawk.com) falhou durante sua janela afetada; as taxas de falha dentro dos ambientes afetados variaram de aproximadamente 37% a 48%, e aproximadamente 41% das solicitações de login-serviço falharam. **Não afetado:** Classificação no carrinho \(e todos os pedidos /api/v4/rates\), processamento de fundo \(todos os trabalhos agendados, write backs, webhooks, geração de etiquetas assync, rastreamento e comunicações operadoras executado normalmente\), integridade de dados. # # Resumo Na manhã de 20 de agosto, uma atualização de segurança crítica do sistema operacional publicada pelo Ubuntu - e aplicada automaticamente pelo nosso processo de patching padrão - continha um defeito no componente do servidor web \(nginx\) que está na frente da aplicação ShipHawk. O pacote afetado foi publicado em 19 de agosto como [USN-8563-3](https://ubuntu.com/security/notices/USN-8563-3). Ubuntu confirmou que esta atualização introduziu uma regressão e publicou [USN-8563-4](https://ubuntu.com/security/notices/USN-8563-4) no mesmo dia, revertendo a alteração problemática na pendência de uma investigação mais aprofundada. Enquanto a versão defeituosa estava em execução, a camada proxy corrompeu a URL de muitos pedidos recebidos antes de entregá-los à aplicação. O aplicativo não pôde corresponder as URLs corrompidas a qualquer endpoint conhecido e respondeu **404 Not Found**. As falhas foram imediatas, rejeições limpas: nenhum pedido foi parcialmente processado, encaminhado para a conta errada ou perdido após a aceitação. Nossos servidores nem todos baixam e instalam atualizações de segurança do sistema operacional no mesmo momento; as verificações de atualização e as janelas de instalação são escalonadas entre os hosts. Como resultado, alguns servidores baixaram o build nginx defeituoso antes do Ubuntu publicar o pacote corrigido, enquanto outros checaram mais tarde e baixaram diretamente o build corrigido. Apenas os servidores que já tinham baixado o pacote defeituoso ficaram afetados quando sua instalação agendada foi executada. É por isso que o problema apareceu intermitente: de outra forma as solicitações idênticas poderiam falhar ou ter sucesso dependendo de qual servidor as lidou. Mesmo nos servidores que executam o pacote nginx defeituoso, apenas um subconjunto de requisições falhou. A regressão afetou regras de roteamento nginx específicas ao invés de toda a configuração proxy, tantos padrões de URL continuaram a funcionar normalmente em um servidor afetado. O incidente foi totalmente resolvido por 08:11 PDT depois que cada servidor afetado foi atualizado para o pacote corrigido e verificado saudável. Nenhuma ação do cliente foi ou é necessária. # # O que foi afetado Os números abaixo contam ** apenas falhas causadas por este incidente**. Respostas comuns de 404 \(pesquisas de registros que genuinamente não existem, URLs inválidas, bot traffic\) foram identificadas por sua assinatura de resposta distinta e excluídas. • Ambiente • Escopo • Janela impactada \(PDT\) --- --- --- --- --- --- --- --- Ambiente sh-p-1, 2 de 3 servidores web, 06:34 - 08:08, 37% dos pedidos nos servidores afetados, 25% do tráfego total da API, Serviço de login , ambos os servidores , 06:33 - 08:08 , 41% dos pedidos de login-serviço , Ambiente sh-p-2, 2 de 3 servidores web, 06:31 - 08:08, 47% dos pedidos em servidores afetados, Ambiente sh-p-3, 2 de 3 servidores web, 06:31 - 08:11, 48% dos pedidos em servidores afetados, □ O que isto parecia na prática: * **As integrações API** receberam respostas HTTP 404 para solicitações válidas. Como as falhas eram imediatas e apátridas, as tentativas dos clientes poderiam ter sucesso quando eles aterrisassem em um servidor não afetado. * **As páginas do Dashboard e login** não conseguiram carregar ou iniciar sessão intermitentemente. * Falhas dependeram da URL exata: alguns tipos de requisição passaram por não afetados mesmo em servidores defeituosos, acrescentando à aparência intermitente. # # O que não foi afetado * **Requisitos de classificação no carrinho.** Todos os pedidos de classificação do portal web, plataformas de comércio eletrônico, plataformas ERP e pedidos regulares de API para `/api/v4/rates estavam funcionando como de costume. * ** Os trabalhos de base não foram afectados. Todo o processamento assíncrono - trabalhos programados, retornos, sincronia de inventário, entregas de webhook, geração de documentos e etiquetas, comunicação transportadora e ERP - corre atrás da camada proxy e continuou normalmente durante todo o incidente. Nenhum trabalho em fila de espera foi perdido ou atrasado. * Integridade dos dados. Nenhum dado foi perdido, alterado ou corrompido. Pedidos preenchidos normalmente ou rejeitados. * ** Segurança e arrendamento. Nenhum pedido foi encaminhado para outra conta, e nenhum limite de segurança foi cruzado. A corrupção ocorreu após todos os controles de acesso foram aplicados. A atualização subjacente do Ubuntu foi um patch de segurança preventiva; a vulnerabilidade que ele abordou não foi explorada em nossos sistemas. # # Timeline \ (todas as vezes PDT, 20 de agosto de 2026\) * ** 19 de agosto \(dia\)** - Ubuntu publica uma atualização de segurança para nginx; um defeito é relatado, e Ubuntu publica um pacote corrigido no mesmo dia. A versão corrigida propaga-se aos espelhos de atualização pública durante a noite. * ** 19 de agosto de 18:24 - 23:09** - A atualização noturna verifica os servidores afetados posteriormente baixar a atualização nginx do dia. Nestes momentos, a construção defeituosa ainda é a mais recente disponível nos espelhos. Esta etapa só baixa o pacote; a instalação acontece durante a janela do patch da manhã seguinte. * **Ago 20, 04:12 - 05:05** - Outro grupo de servidores executa sua verificação de atualização noturna após a compilação corrigida atingir os espelhos. Esses servidores baixam a versão fixa e permanecem saudáveis durante todo o incidente. * **~06:00** - Uma atualização de configuração de aplicação de rotina e não relacionada é aplicada para as próximas versões. Ele não tem efeito na funcionalidade atualmente lançada e ** não desempenha nenhum papel no incidente**, mas porque é a única mudança conhecida naquela manhã, torna-se o primeiro suspeito uma vez que erros aparecem. * **06:00** - A janela automática de patching começa a rolar atualizações nginx em ambientes. Alguns servidores já têm o pacote corrigido baixado, enquanto outros têm o pacote defeituoso. * **06:31 - 06:34 - INÍCIO. À medida que a janela de patch automático de rolamento progride, o pacote nginx com falhas anteriormente baixado é instalado em vários servidores web e login em ambientes de produção compartilhados. Porque os agendamentos de patches são escalonados, nem todos os servidores se atualizam de uma vez, e alguns servidores permanecem saudáveis. As primeiras solicitações falhadas para o cliente começam em **06:31**. * **06:35** - Alertas de monitoramento externo automatizados sobre erros elevados. **Investigação começa imediatamente. * **06:36 - 07:15** - Os engenheiros primeiro investigam a atualização de configuração ~06:00, a única alteração conhecida no nível de aplicação com o tempo correspondente. É descartado, e a atenção gira para a camada web/proxy. * **06:52** - A janela do patch continua e o pacote defeituoso é ativado em servidores adicionais. O impacto aumenta à medida que os servidores mais afetados reiniciam a versão nginx defeituosa, enquanto os servidores que baixaram o pacote corrigido do Ubuntu permanecem saudáveis. * **06:55** - Um servidor web restante atualiza usando o pacote corrigido do Ubuntu e permanece saudável durante todo o tempo, continuando a servir sua parte do tráfego corretamente. * **07:18 - 07:19** - Servidores web afetados são reiniciados como uma tentativa de mitigação. Isto não tem efeito porque o pacote nginx defeituoso permanece instalado. * **07:20 - 07:55** - Servidores suspeitos são removidos da rotação balanceador de carga. Os sintomas persistem porque o serviço de login e os ambientes de aplicação são afetados independentemente, o que materialmente amplia a busca. * **07:41** - O padrão URL-corrupção é identificado em logs de aplicativos. * **07:45 - 08:00** - Teste por servidor isola os servidores defeituosos. A única diferença entre servidores saudáveis é a versão do pacote nginx. O build defeituoso é compatível com o aviso de regressão publicado pelo Ubuntu e pacote corrigido. * **08:02 - 08:11** - O pacote corrigido é instalado em todos os servidores afetados. As taxas de erro retornam ao normal imediatamente em cada servidor ao reiniciar a versão fixa. O ambiente final afetado retorna ao normal em **08:11 - INCIDENTE RESOLVIDO TOTALMENTE**. * **08:11\+** - Verificação completa é concluída: cada servidor é testado individualmente, e API, painel, login e ambientes de produção são confirmados saudáveis. # # Por que a resolução levou ~95 minutos do alerta A detecção foi rápida, mas três fatores retardaram o diagnóstico. Primeiro, uma mudança de configuração de rotina mais cedo naquela manhã foi a única mudança conhecida no ambiente e teve que ser descartada - o patch de OS automatizado não aparece em nenhum log de alterações de nível de aplicação. Em segundo lugar, a falha foi intermitente por natureza: servidores não afetados continuaram servindo normalmente, e até mesmo os servidores afetados lidaram com sucesso com tipos de solicitação cujas regras de roteamento não foram impactadas. Em terceiro lugar, a remoção dos servidores suspeitos da rotação não impediu os erros - porque outras camadas foram afetadas de forma independente - que inicialmente apontavam a investigação para longe desses servidores. # # O que estamos mudando **1. Etapa patches de segurança do sistema operacional antes da produção.** Atualizações automáticas de segurança de nível OS e nginx, incluindo correções críticas, serão primeiramente instaladas em servidores não-produção. A validação automatizada do nível de aplicação irá exercer API representativa, painel e caminhos de login contra os servidores atualizados antes que as mesmas versões do pacote sejam permitidas a entrar em produção. O lançamento da produção só começará após os controlos passarem. 2. Diagnóstico mais rápido em nível de versão. Nossos runbooks de incidentes agora incluem comparação imediata de versões de pacotes e reiniciar o histórico entre servidores sempre que servidores configurados de forma idêntica se comportam de forma diferente.

Traduzido automaticamente da atualização oficial do incidente.

1. 26 Mezheven 2026 da 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 Mezheven 2026 da 20:49 UTCresolved

   Resolved by FedEx

1. 19 Mezheven 2026 da 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 Mezheven 2026 da 02:17 UTCresolved

   This incident has been resolved.

1. 18 Mae 2026 da 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 Mae 2026 da 21:43 UTCresolved

   Resolved by PrintNode.

1. 23 Cʼhwevrer 2026 da 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 Cʼhwevrer 2026 da 22:52 UTCresolved

   Resolved by FedEx.

1. 20 Here 2025 da 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 Here 2025 da 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 Here 2025 da 23:28 UTCresolved

   The AWS issue affecting carriers has been resolved.

1. 10 Here 2025 da 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 Here 2025 da 18:18 UTCresolved

   Resolved by USPS Endicia

1. 29 Gwengolo 2025 da 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 Gwengolo 2025 da 22:40 UTCresolved

   Confirmed as resolved by WWEX.

1. 20 Mezheven 2025 da 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 Mezheven 2025 da 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 Mezheven 2025 da 17:21 UTCmonitoring

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

4. 21 Mezheven 2025 da 04:07 UTCresolved

   This incident has been resolved.

1. 5 Mae 2025 da 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 Mae 2025 da 23:10 UTCresolved

   This incident has been resolved.

1. 14 Ebrel 2025 da 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 Ebrel 2025 da 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 Ebrel 2025 da 20:47 UTCresolved

   This incident has been resolved.

1. 11 Meurzh 2025 da 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 Meurzh 2025 da 12:00 UTCmonitoring

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

3. 11 Meurzh 2025 da 22:34 UTCresolved

   This incident has been resolved.

1. 30 Genver 2025 da 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 Genver 2025 da 15:59 UTCresolved

   Resolved by Pitney Bowes

1. 25 Gouere 2024 da 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 Gouere 2024 da 20:00 UTCmonitoring

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

3. 26 Gouere 2024 da 00:14 UTCresolved

   This incident has been resolved.

1. 18 Mezheven 2024 da 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 Mezheven 2024 da 23:19 UTCresolved

   Resolved by Endicia.

1. 17 Mezheven 2024 da 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 Mezheven 2024 da 17:01 UTCresolved

   Resolved by FedEx.

1. 22 Mae 2024 da 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 Mae 2024 da 20:20 UTCresolved

   Resolved by FedEx team.

1. 17 Mae 2024 da 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 Mae 2024 da 22:41 UTCresolved

   Resolved by UPS.