Post agendado não foi publicado: o que fazer
As causas mais comuns de um post agendado não sair, e como diferenciar cada uma.
Por André LugUm post agendado que nunca sai é um dos momentos mais estressantes de um calendário de marketing — a campanha foi planejada, o texto foi aprovado, e nada apareceu. Se você não é quem construiu a integração, as mensagens de erro que a sua ferramenta mostra (ou não mostra) raramente explicam o que de fato aconteceu. Este é um mapa em português claro das causas reais, mais ou menos na ordem que vale a pena checar primeiro.
A conta conectada perdeu acesso
De longe a causa mais comum: o token de acesso por trás da conexão expirou, foi revogado ou perdeu uma permissão que precisava. Isso acontece porque alguém trocou a senha da conta, um administrador removeu o acesso do app nas próprias configurações de segurança da plataforma, uma Página ou conta comercial trocou de gestor, ou a própria plataforma exige reautorização periodicamente. O post nunca chegou a ser tentado — a ferramenta nem conseguiu alcançar a conta para tentar.
O que checar: a ferramenta mostra a conexão como saudável agora, independente do post que falhou? Se a própria conexão precisa ser reconectada, essa é a correção — e ela não tem nada a ver com o post específico que falhou.
A plataforma rejeitou o conteúdo em si
Toda plataforma aplica as próprias regras de conteúdo no momento da publicação, separadamente do que a sua ferramenta checa antecipadamente: limite de caracteres na legenda, caracteres ou links não suportados, uma imagem ou vídeo que não atende requisitos de formato/dimensão/duração, ou uma legenda que aciona filtros automáticos de política de conteúdo. Vídeo é a fonte mais comum de rejeição silenciosa — um codec, proporção ou duração que a plataforma recusa discretamente sem um erro claro chegar até o seu painel.
O que checar: o motivo da falha menciona o conteúdo em si (formato, tamanho, política) em vez da conexão ou do agendamento? Se sim, a correção é editar o post, não a integração.
A conta ou o app bateu num limite de taxa
Plataformas limitam quanto uma conta (e às vezes o app que publica em seu nome) pode postar numa determinada janela. Se vários posts foram enfileirados próximos, ou a mesma conta está conectada a mais de uma ferramenta publicando em seu nome, um post agendado pode simplesmente ser recusado por exceder um limite que não tem nada a ver com aquele conteúdo específico.
O que checar: outros posts na mesma época tiveram sucesso ou falharam juntos? Um agrupamento de falhas em posts sem relação entre si, na mesma conta, no mesmo horário, aponta para um limite de taxa, não para um problema de conteúdo.
Uma falha transitória do lado da plataforma
Às vezes o próprio pipeline de publicação da plataforma tem uma instabilidade breve ou um momento incomumente lento, e uma requisição que normalmente teria sucesso expira ou é rejeitada com um erro genérico de servidor. Este é o caso mais difícil de distinguir dos outros sem uma boa ferramenta, porque a falha não é realmente sobre o seu conteúdo, a sua conexão ou a sua conta — é má sorte no timing.
Uma integração bem construída retenta isso automaticamente (com backoff, para não piorar uma instabilidade) e só expõe como uma falha real depois que as retentativas se esgotam — veja Erros e retentativas para como o PostGate classifica falhas retentáveis versus definitivas.
A armadilha: achar que "sem erro mostrado" quer dizer que funcionou
O modo de falha que mais causa estrago não é um erro alto — é o silêncio. Uma ferramenta que reporta sucesso no momento em que aceita a sua requisição (em vez do momento em que a plataforma realmente confirma a entrega) pode deixar um post agendado parecendo "concluído" no seu calendário enquanto ele falhou silenciosamente minutos depois. Se a sua ferramenta não mostra um status de entrega distinto, por post, depois que o horário agendado passa, você não consegue de fato diferenciar sucesso de uma falha não percebida — veja por que contas de redes sociais desconectam sozinhas para o lado de conexão dessa mesma armadilha.
Acompanhando o status real, não só a aceitação
A resposta de criação de um post é a aceitação da requisição, não a prova de que o conteúdo existe em alguma plataforma. A entrega para cada destino é assíncrona e rastreada de forma independente, e o estado real de um post só é conhecido lendo targets, não pelo formato da resposta de criação. Cada alvo progride por pending, media_ready e publishing, às vezes por reconciling ou retry_scheduled quando uma falha transitória precisa de outra tentativa, e só então chega a um resultado terminal: published, failed ou skipped.
curl https://api.postgate.studio/api/posts/post_01JXYZ \
-H "Authorization: Bearer $POSTGATE_API_KEY"
{
"id": "post_01JXYZ",
"status": "failed",
"targets": [
{
"profile_id": "pro_instagram123",
"status": "failed",
"error": { "code": "content_rejected", "retryable": false },
"attempts": 1
}
]
}Como o PostGate ajuda aqui
O PostGate nunca confunde "aceitou a requisição" com "entregou". Todo post agendado carrega um status por destino ao longo de scheduled → processing → published/partial/failed, e uma falha reporta um motivo estruturado, marcado por plataforma, em vez de um erro genérico — veja Ciclo de entrega. Os webhooks post.failed e post.partial (Webhooks) deixam você pegar uma falha real no momento em que acontece, em vez de descobrir quando um cliente percebe que o post está faltando.
