{"id":184,"date":"2026-09-16T19:20:23","date_gmt":"2026-09-16T22:20:23","guid":{"rendered":"https:\/\/postping.com.br\/blog\/post-agendado-wordpress-disparo-redes\/"},"modified":"2026-09-16T19:20:23","modified_gmt":"2026-09-16T22:20:23","slug":"post-agendado-wordpress-disparo-redes","status":"publish","type":"post","link":"https:\/\/postping.com.br\/blog\/post-agendado-wordpress-disparo-redes\/","title":{"rendered":"Post agendado no WordPress e o disparo nas redes sociais"},"content":{"rendered":"<p>Este blog publicou <strong>27<\/strong> artigos desde 19 de agosto. Dezenove deles sa\u00edram na mesma janela da noite e nenhum saiu no mesmo segundo: o mais adiantado entrou \u00e0s <strong>19:18:27<\/strong>, o mais atrasado \u00e0s <strong>19:25:43<\/strong>. S\u00e3o 7 minutos e 16 segundos de espalhamento, distribu\u00eddos em sete minutos diferentes do rel\u00f3gio, para uma tarefa que tem hora marcada e roda sozinha todo dia.<\/p>\n<p>Ningu\u00e9m mexeu na configura\u00e7\u00e3o entre um dia e outro. A hora marcada \u00e9 um pedido; a execu\u00e7\u00e3o \u00e9 um segundo evento, e ele acontece quando a m\u00e1quina chega nele. Quem agenda post no WordPress convive com a mesma dist\u00e2ncia, com um detalhe que muda a escala do problema: ali o que empurra a fila n\u00e3o \u00e9 um rel\u00f3gio, \u00e9 uma visita ao site. E quando a publica\u00e7\u00e3o \u00e9 o primeiro elo de uma esteira que ainda tem que postar no Instagram e avisar a equipe, o atraso n\u00e3o termina no atraso.<\/p>\n<h2>O que os 19 carimbos medem, e o que n\u00e3o medem<\/h2>\n<p>Os artigos daqui n\u00e3o passam pelo agendador do WordPress. Uma rotina di\u00e1ria escreve direto na REST API com o status j\u00e1 em <code>publish<\/code>, ent\u00e3o o hor\u00e1rio gravado \u00e9 o instante em que a rotina conseguiu rodar. O espalhamento de sete minutos \u00e9 do agendador que chama a rotina, n\u00e3o do WP-Cron.<\/p>\n<p>O n\u00famero serve como piso. Aquele agendador \u00e9 um cron de verdade: roda em m\u00e1quina dedicada, n\u00e3o depende de tr\u00e1fego nenhum, ningu\u00e9m disputa o hor\u00e1rio com ele. Mesmo assim variou sete minutos em dezenove tentativas. O WP-Cron trabalha em condi\u00e7\u00f5es bem piores, e a varia\u00e7\u00e3o dele n\u00e3o se mede em minutos, se mede em quando algu\u00e9m abre uma p\u00e1gina do seu site.<\/p>\n<p>Tem um caso mais gritante nesses 27 artigos: um deles n\u00e3o caiu na janela da noite. Saiu \u00e0s <strong>9:17<\/strong> da manh\u00e3, dez horas antes do hor\u00e1rio dos outros dezenove. N\u00e3o h\u00e1 como saber o que aconteceu naquele dia, e \u00e9 exatamente esse o ponto. N\u00e3o existe registro de tentativa, de atraso nem de recupera\u00e7\u00e3o em lugar nenhum. Sobrou um carimbo de hor\u00e1rio fora do padr\u00e3o, que s\u00f3 apareceu porque algu\u00e9m foi contar. \u00c9 assim que agendamento quebrado se parece por dentro: n\u00e3o como erro, como uma data diferente da combinada.<\/p>\n<h2>Onde o WordPress guarda a hora que voc\u00ea marcou<\/h2>\n<p>Quando voc\u00ea salva um artigo com data futura, o status dele vira <code>future<\/code> e o WordPress cria um evento \u00fanico de cron para aquele post espec\u00edfico. A fun\u00e7\u00e3o respons\u00e1vel \u00e9 <code>_future_post_hook()<\/code>, e ela faz duas coisas na ordem: limpa qualquer agendamento anterior daquele post e agenda um novo evento <code>publish_future_post<\/code> para o timestamp GMT da data que voc\u00ea escolheu.<\/p>\n<p>Na hora marcada, quem atende \u00e9 <code>check_and_publish_future_post()<\/code>. Ela confere se o post ainda est\u00e1 em <code>future<\/code>, compara a data com o momento atual e decide: se o hor\u00e1rio ainda n\u00e3o chegou, reagenda o evento e sai sem publicar; se j\u00e1 passou, chama <code>wp_publish_post()<\/code> e o artigo vai ao ar.<\/p>\n<p>Repare que n\u00e3o existe nenhuma verifica\u00e7\u00e3o de atraso nessa compara\u00e7\u00e3o. O c\u00f3digo pergunta se a hora j\u00e1 passou, n\u00e3o quanto tempo faz que passou. Um evento que deveria ter rodado \u00e0s 9h e s\u00f3 roda \u00e0s 14h publica o artigo \u00e0s 14h sem reclamar, e \u00e9 por isso que a maioria dos atrasos de agendamento passa em branco: do ponto de vista do WordPress, aquilo funcionou.<\/p>\n<h2>Quem aperta o gatilho \u00e9 a visita, n\u00e3o o rel\u00f3gio<\/h2>\n<p>O evento est\u00e1 agendado, a fun\u00e7\u00e3o est\u00e1 pronta, e nada disso roda por conta pr\u00f3pria. A documenta\u00e7\u00e3o do WordPress \u00e9 direta sobre o mecanismo: \u201cWP-Cron works by checking, on every page load, a list of scheduled tasks to see what needs to be run.\u201d \u00c9 uma checagem por carregamento de p\u00e1gina.<\/p>\n<p>Na pr\u00e1tica, a fun\u00e7\u00e3o <code>wp_cron()<\/code> pendura a execu\u00e7\u00e3o na a\u00e7\u00e3o <code>shutdown<\/code> da requisi\u00e7\u00e3o. Ou seja: algu\u00e9m precisa abrir uma p\u00e1gina, o PHP precisa processar essa p\u00e1gina at\u00e9 o fim, e s\u00f3 ent\u00e3o a fila de tarefas \u00e9 olhada. Sem requisi\u00e7\u00e3o, a fila fica intacta por quanto tempo for.<\/p>\n<p>A pr\u00f3pria documenta\u00e7\u00e3o d\u00e1 o exemplo em que isso d\u00f3i: \u201cScheduling errors could occur if you schedule a task for 2:00PM and no page loads occur until 5:00PM.\u201d Tr\u00eas horas de atraso, sem erro, sem aviso. Em blog novo, em blog de nicho, em site institucional que recebe visita em hor\u00e1rio comercial e sil\u00eancio de madrugada, agendar para 6h da manh\u00e3 \u00e9 agendar para o primeiro visitante depois das 6h.<\/p>\n<p>Esse \u00e9 o comportamento padr\u00e3o, e ele tem rem\u00e9dio oficial. A documenta\u00e7\u00e3o recomenda desligar o gatilho por visita com <code>define( 'DISABLE_WP_CRON', true );<\/code> no <code>wp-config.php<\/code> e chamar o arquivo de fora, por um cron de sistema, com uma linha do tipo <code>wget --delete-after http:\/\/SEU_SITE\/wp-cron.php<\/code>. A partir da\u00ed a fila passa a ser olhada em intervalo fixo, independente de quem entrou no site.<\/p>\n<h2>O cache que impede o PHP de acordar<\/h2>\n<p>Existe um caso pior que o site sem tr\u00e1fego: o site com tr\u00e1fego cujas visitas n\u00e3o acordam o PHP. Cache de p\u00e1gina entrega HTML pronto do disco ou da mem\u00f3ria, sem executar o WordPress. A visita acontece, o visitante \u00e9 servido, e a a\u00e7\u00e3o <code>shutdown<\/code> do WordPress nunca \u00e9 alcan\u00e7ada porque o WordPress n\u00e3o rodou.<\/p>\n<p>No f\u00f3rum oficial existe o relato inteiro desse cen\u00e1rio. O autor do t\u00f3pico descreve o sintoma com as palavras de quem s\u00f3 v\u00ea a tela: \u201cThe time\/date passes, and I see a red \u2018missed schedule\u2019 error.\u201d Nenhum plugin novo, nenhuma mudan\u00e7a de hospedagem, agendamento que funcionava e parou. O suporte pediu para desativar o plugin de cache, o post de teste saiu na hora, e a investiga\u00e7\u00e3o seguiu para descobrir qual configura\u00e7\u00e3o espec\u00edfica de cache de p\u00e1gina estava servindo tudo est\u00e1tico.<\/p>\n<p>\u00c9 um diagn\u00f3stico que quase nunca \u00e9 o primeiro palpite, porque cache e agendamento parecem assuntos de departamentos diferentes. S\u00e3o o mesmo assunto quando o agendador depende de execu\u00e7\u00e3o de PHP.<\/p>\n<h2>O post sai e o envio \u00e0 rede fica para tr\u00e1s<\/h2>\n<p>At\u00e9 aqui o problema era o artigo ir ao ar. Agora entra o elo seguinte, e ele tem uma falha pr\u00f3pria.<\/p>\n<p>Quando o artigo agendado finalmente vira p\u00fablico, <code>wp_publish_post()<\/code> chama <code>wp_transition_post_status()<\/code>, que dispara a a\u00e7\u00e3o <code>transition_post_status<\/code> com o status novo, o status antigo e o objeto do post. Um plugin que escuta essa troca recebe o post agendado igual ao post publicado \u00e0 m\u00e3o: para ele, a origem do <code>publish<\/code> n\u00e3o faz diferen\u00e7a. Essa \u00e9 a raz\u00e3o t\u00e9cnica de o agendamento do WordPress e a publica\u00e7\u00e3o autom\u00e1tica na rede conseguirem conviver sem gambiarra.<\/p>\n<p>O problema \u00e9 que o envio \u00e0 rede raramente acontece dentro dessa mesma requisi\u00e7\u00e3o, e n\u00e3o deveria: postar no Instagram s\u00e3o duas chamadas HTTP \u00e0 Graph API, uma para criar o cont\u00eainer de m\u00eddia em <code>\/media<\/code> e outra para publicar em <code>\/media_publish<\/code>. Segurar o salvamento do post esperando resposta da Meta \u00e9 pedir para o editor travar. O caminho sensato \u00e9 agendar o envio para segundos depois, e a\u00ed a esteira volta a depender do cron que j\u00e1 se mostrou fr\u00e1gil.<\/p>\n<p>Pior: o <code>wp-cron.php<\/code> remove o evento da fila <em>antes<\/em> de execut\u00e1-lo. Na ordem exata do arquivo, o timestamp \u00e9 conferido, o evento recorrente \u00e9 reagendado, <code>wp_unschedule_event()<\/code> \u00e9 chamado, e s\u00f3 ent\u00e3o <code>do_action_ref_array()<\/code> roda o gancho. Se o PHP estourar o tempo no meio do envio, o evento j\u00e1 n\u00e3o existe mais. O artigo est\u00e1 publicado, o registro diz que o envio est\u00e1 pendente, e n\u00e3o h\u00e1 nada agendado para cham\u00e1-lo de volta.<\/p>\n<h2>O que o atraso faz com a janela da Meta<\/h2>\n<p>Na maior parte dos casos, atraso de publica\u00e7\u00e3o \u00e9 s\u00f3 um problema de pontualidade. H\u00e1 dois pontos em que ele passa a quebrar coisa.<\/p>\n<p>O primeiro \u00e9 o cont\u00eainer de m\u00eddia. Criar o cont\u00eainer e public\u00e1-lo s\u00e3o etapas separadas, e a documenta\u00e7\u00e3o de publica\u00e7\u00e3o de conte\u00fado do Instagram avisa que o cont\u00eainer n\u00e3o publicado em 24 horas expira. Uma esteira que cria o cont\u00eainer na hora do <code>publish<\/code> e tenta publicar depois, num segundo evento de cron que ficou preso, tem esse teto para acordar. Passou de 24 horas, o cont\u00eainer morreu e o envio precisa come\u00e7ar de novo.<\/p>\n<p>O segundo \u00e9 a fila que se acumula. A conta do Instagram aceita <strong>100<\/strong> publica\u00e7\u00f5es por API dentro de uma janela m\u00f3vel de 24 horas, com carrossel contando como uma. Cem \u00e9 bastante para um blog; deixa de ser bastante quando quatro dias de agendamento atrasado destravam juntos porque algu\u00e9m finalmente visitou o site, e a ag\u00eancia que cuida de v\u00e1rios perfis sente isso antes. A janela \u00e9 m\u00f3vel, ent\u00e3o n\u00e3o zera \u00e0 meia-noite: ela zera 24 horas depois de cada envio.<\/p>\n<p>Fora da t\u00e9cnica sobra o efeito mais \u00f3bvio e o menos discutido. Artigo agendado para as 9h que sai \u00e0s 14h perde a raz\u00e3o de ter sido agendado para as 9h, e o post na rede sai no hor\u00e1rio errado junto. Quem agenda para ganhar hor\u00e1rio est\u00e1 comprando exatamente aquilo que o WP-Cron n\u00e3o garante, e esse custo tem uma conta pr\u00f3pria que j\u00e1 detalhamos em <a href=\"https:\/\/postping.com.br\/blog\/agendar-post-instagram-custo-semanal\/\">agendar post no Instagram e o custo que volta toda semana<\/a>.<\/p>\n<h2>A rede de seguran\u00e7a precisa existir nos dois lados<\/h2>\n<p>Do lado do WordPress, o rem\u00e9dio \u00e9 o cron de sistema descrito acima. Ele resolve o atraso de publica\u00e7\u00e3o e n\u00e3o resolve o envio que morreu no meio, porque esse envio n\u00e3o est\u00e1 mais agendado para ningu\u00e9m encontrar.<\/p>\n<p>Do lado do envio, o que funciona \u00e9 algu\u00e9m revisitar o estado depois. No Post Ping isso \u00e9 uma verifica\u00e7\u00e3o di\u00e1ria que procura artigos publicados que n\u00e3o foram notificados e trata cada um como pend\u00eancia aberta, em vez de confiar que o evento de cron original deu conta. A detec\u00e7\u00e3o da publica\u00e7\u00e3o \u00e9 a mesma descrita acima, pela troca de status, ent\u00e3o o artigo agendado entra na esteira sem nenhum passo extra na reda\u00e7\u00e3o. As duas coisas est\u00e3o descritas em <a href=\"https:\/\/postping.com.br\/recursos\">recursos<\/a>.<\/p>\n<p>Nenhuma das duas pe\u00e7as substitui a outra. Cron de sistema sem repescagem publica na hora e perde envios; repescagem sem cron de sistema envia tudo, sempre tarde.<\/p>\n<h2>Por que voc\u00ea n\u00e3o consegue auditar o atraso depois<\/h2>\n<p>Aqui est\u00e1 a parte que surpreende quem vai procurar evid\u00eancia: ela n\u00e3o existe. A fun\u00e7\u00e3o <code>wp_publish_post()<\/code> faz um \u00fanico <code>UPDATE<\/code> na tabela de posts, e esse update grava um campo s\u00f3, o <code>post_status<\/code>. A data do post continua sendo a data que voc\u00ea marcou. O <code>post_modified<\/code> n\u00e3o \u00e9 tocado.<\/p>\n<p>Ent\u00e3o um artigo agendado para as 9h e publicado de fato \u00e0s 14h fica registrado como publicado \u00e0s 9h, para sempre, em todos os lugares que leem esse campo: a lista de posts, o feed, o sitemap, a REST API. Se o agendamento do WordPress fosse o que publica este blog, os 27 carimbos do come\u00e7o deste artigo n\u00e3o serviriam para medir atraso nenhum: eles marcariam o pedido, n\u00e3o a entrega.<\/p>\n<p>Quem quer o n\u00famero real precisa medir do lado de fora. O registro de envio \u00e0s redes tem a hora verdadeira, porque \u00e9 gravado quando a chamada acontece. Comparar essa hora com a data do post \u00e9 a \u00fanica forma de saber se o agendamento est\u00e1 cumprindo o hor\u00e1rio, e \u00e9 uma compara\u00e7\u00e3o que vale fazer uma vez por m\u00eas em blog que agenda.<\/p>\n<p>Se o ponto de partida for antes disso, e a d\u00favida for como a publica\u00e7\u00e3o sai do WordPress e chega \u00e0s redes sem ningu\u00e9m apertar bot\u00e3o, o caminho inteiro est\u00e1 em <a href=\"https:\/\/postping.com.br\/blog\/wordpress-instagram-facebook-automatico\/\">publicar do WordPress no Instagram e Facebook automaticamente<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Post agendado no WordPress depende de uma visita ao site para ir ao ar. Medimos 19 publica\u00e7\u00f5es deste blog e mostramos onde a esteira at\u00e9 a rede atrasa.<\/p>\n","protected":false},"author":1,"featured_media":183,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-184","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-publicacao-automatica"],"_links":{"self":[{"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/posts\/184","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/comments?post=184"}],"version-history":[{"count":0,"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/posts\/184\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/media\/183"}],"wp:attachment":[{"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/media?parent=184"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/categories?post=184"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/tags?post=184"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}