Hostpoint or manitu for checking an incoming webhook after a WordPress migration

The page responds, but did the webhook follow?

A small team publishes its documentation on WordPress. When a version of its software is released, a GitHub webhook notifies the site and triggers preparation of a draft release note. The team moves WordPress to another host while keeping the same domain name. The homepage responds on the new hosting account. Meanwhile, requests may still reach the old one, and a GET check says nothing about the POST that must prepare the draft.

On switchover evening, compare three traces for each release. GitHub indicates whether the HTTP delivery was accepted. The receiver indicates whether the signed delivery entered its queue. Background processing indicates whether the draft was created or updated. Record the delivery identifier, release identifier and UTC time. This lets you explain a missing or replayed event without consulting signed content in a log.

Hostpoint Standard Web Hosting and manitu Webhosting M are two shared hosting offers that can run a PHP receiver and schedule processing. The choice depends on database space, the permitted delay before the draft appears and the ability to follow the same request between both hosts. PHP and scheduler limits describe resources separate from GitHub’s response deadline.

Two plans for a lightweight receiver

Hostpoint lists its Standard Web Hosting at CHF 15.90 including VAT per month, with 100 GB of web storage and ten MariaDB databases. Twelve months at the same price total CHF 190.80 based on the displayed rate. Its help cites hosting terms of six, twelve or twenty-four months, with automatic renewal for the same term and cancellation no later than thirty days before expiry. Check the offered cycle, your invoice’s tax treatment and contract total. The panel documents downloading access and error logs by site and date.

manitu’s comparison lists Webhosting M at €1.00 per month for six months, then €5.99, at the German gross price with 19% VAT. It states an initial twelve-month commitment, billed in advance, followed by a one-month extension and six-monthly billing in advance. These two durations answer different questions. The stated notice period is two weeks. At the recorded German rate and excluding options, allow €41.94 for the first year. Twelve months at the regular rate provide a reference of €71.88 if the price remains stable. The site states a gross price depending on the selected country.

For a new manitu M account, the comparison table distinguishes 50 GB of web storage and 50 GB of email storage. The offer card advertises 100 GB of storage. To size WordPress files, use the table’s web quota and confirm the account’s allocation. The table also advertises five databases, each limited to 1 GB, and five cron jobs with 120 seconds per execution and up to twelve executions per hour per job. Measure existing table volume before adding the queue. If it fits in a separate database, also include that database’s backup and permission tracking in acceptance testing. Both providers document web logs. An access trace may help identify the server and response, while the delivery identifier and draft status must come from the application.

Test the POST that will actually arrive

On the private copy, identify the exact URL receiving the webhook, the expected event type and the version of signature-verification code. Exclude this route from caching and general redirects that might replace or divert the POST. A maintenance page, interactive authentication prompt or static homepage can respond correctly to visitors while making the route unusable for the sender. Serve the route under the intended certificate and domain name.

In the GitHub example, the receiver checks the signature header using the webhook secret and raw body before decoding JSON. The code compares the signature in constant time and checks that the event and action match the expected case, here a published release from an intended repository. Install the secret in server configuration and keep it out of URLs, logs and artifacts. For testing, use demo events and a demo secret in a controlled environment.

A 2xx response is meaningful only if it follows durable recording of the delivery. Save the identifier and what processing requires in a short transaction. Respond quickly after confirming the write. GitHub expects a 2xx response within ten seconds. A heavy WordPress page, an external call or writing the entire draft within the request reduces this margin. An unavailable database must surface an observable error instead of hiding the event behind a success page.

Keep deliveries while the old server still responds

Prepare a window during which the old server remains accessible, with UTC markers on both copies. Keep the webhook URL and secret when the migration allows. The domain name may remain identical while two origins succeed one another. Identify the origin that accepted each request in the application log. If you also change the URL configured at the sender, note the exact time and check which route will receive redeliveries.

Two temporary receivers are acceptable if they write to the same durable register and the effect is applied by a single authorized processor. manitu’s table states that its databases cannot be reached externally. With a manitu database, favor a single stable entry point. Hostpoint’s Web Hosting guide describes authorizing an external host for a database user. Confirm permissions on Standard, both accounts’ network restrictions and the ability to use a protected connection before choosing a shared register. If that route is unavailable, choose a stable entry point or briefly suspend reception during transition. In the latter case, make failure explicit and reconcile attempts from that window in GitHub before closing the transfer.

An old copy accepting a delivery into an abandoned database can make GitHub display success. The new host then has nothing to process. If databases must remain separate, revoke permission to accept deliveries on the old copy before authorizing the new one. An initial database backup contains no deliveries received after export. Precisely record the last transferred identifier and inspect both logs during overlap.

Separate delivery from its effect

The delivery identifier answers “have we already recorded this request?”. The draft answers a different question. Record a stable business key, such as the repository and published release identifier. On GitHub redelivery, the X-GitHub-Delivery header keeps its original value. Another delivery identifier may nevertheless refer to the same release in an integration or acceptance test. Processing must find the same draft. A uniqueness constraint protects the queue against two concurrent inserts.

Processing rereads pending rows in small batches. In the mockup, the effect and status update share a transaction. When real WordPress or an external service cannot provide this atomicity, use a repeatable write based on the business key and a processing state you can reconcile. After a crash between draft creation and delivery marking, find the draft by its key before retrying. An action already sent to an external service requires checking that service. SQLite atomicity in the mockup does not prove that of a WordPress or external operation.

Make states readable. A pending row has passed entry checks but awaits the next batch. A processed row points to a draft identifier. A retryable error carries a counter and last-attempt time. A row excluded because its event is outside scope must be distinguished from a lost delivery. Define how long to keep this evidence, how much body data to store and who can access logs. An identifier and hash may suffice after processing.

Size the queue and measure its delay

On manitu M, the limit of twelve executions per hour per job makes a periodic check every five minutes consistent with the published limits. The wait before the first pass can approach five minutes when all is well. It increases if batches accumulate or the process fails. The permitted 120 seconds per job imposes a per-batch budget. Measure how many rows are actually processed during an execution and retain a margin before available time ends.

At Hostpoint, the cron manager documents an every-five-minute example. This configuration does not establish a guaranteed processing deadline. Check execution parameters actually available on Standard. Pair panel logs with an application processing status and a measurement of the oldest pending event. Test cron output during acceptance testing to distinguish a processing failure from an absence of deliveries.

Suppose your test applies twenty updates per pass and forty-five events arrive simultaneously. If no other rows arrive and every pass works, three are needed. With one pass every five minutes, the end of the final batch can occur up to approximately fifteen minutes after arrival, plus the batch’s processing time. If the editorial team expects an update within two minutes, adapt the architecture or accepted deadline. Keep HTTP response time separate from the age of the oldest pending event.

Also measure queue size including indexes and history. On manitu M, a WordPress database already near 1 GB does not gain headroom because the plan advertises 50 GB of web storage. On both offers, webhook volumes far beyond this small-site scenario require a controlled load test, a purge policy and an estimate of drain time after a failure. The three-pass calculation illustrates throughput using fictional values.

Reconcile attempts before removing the old site

In GitHub, retrieve delivery attempts since the last checkpoint before switchover. Compare them with the shared register or, if reception had to stop, the imported log and new site’s log. For a failed attempt with an already recorded identifier, check processing before retrying. The write may have succeeded without the response being received. A second send of the same identifier must leave only one row.

A successful HTTP attempt matching no queue entry also requires action. First check whether the request reached the old copy, cache or a generic page. Correct the destination, request delivery again and verify the write. GitHub does not automatically redeliver failed webhooks. Its documentation says deliveries from the last three days can be resent. Schedule checking and recovery within this window.

If a delivery falls outside the recovery window, compare business state with the list of already published releases. Reconstruct missing drafts from an approved source and link the correction to the migration log. On the real site, confirm that drafts remain private and old processing can no longer change data. Recording totals alone can conceal a duplicate and an absence that offset each other. Check identifiers row by row over the short transfer period.

Replay the scenario offline

The acceptance-test ZIP runs two local HTTP servers and a shared SQLite register. Test requests are signed and sent to both origins. The first test receives 200 on the homepage and 404 on an incorrect POST path. A POST with an incorrect signature is rejected. A generic page also returns a real 200 while the register counter remains unchanged. The test replays this delivery and a 503 attempt after restoring the correct destination.

The old server accepts the first delivery. The test bench then assumes the sender did not observe its acknowledgment and makes it resend the same identifier to the new server. The register retains one entry and preserves the origin of the first write. Another delivery of the same business event fills a separate queue row. It must lead to the same release draft, checking the distinction between both keys.

Processing inserts a draft and then triggers a crash before the transaction ends. The database rolls back the insert. Retrying processes the four entries and produces three drafts. An additional pass changes nothing. The report gives HTTP codes and counters before and after processing. It demonstrates these behaviors in the mockup, where effect and status share SQLite. Perform separate acceptance testing of DNS, the certificate, scheduler and draft persistence in the real environment.

• Extract the ZIP into an empty folder. Run python recette.py with Python 3.10 or later.
• Compare HTTP codes and counters. Both a 200 without a record and a 503 are recovered by the acceptance test.
• Check that the four deliveries produce three drafts and an additional pass creates no effect. Then replay the checks specific to your hosting and integration.

Decide based on delay and evidence

Hostpoint Standard is suitable if downloadable logs make switchover tracking easier and your team can monitor the queue with a tested cron. Its ten databases offer flexibility to separate testing or the queue from WordPress. Check the per-database limit and access conditions if a register shared between two origins is required. Compare the displayed monthly price with the chosen term and coexistence period.

manitu Webhosting M is suitable if the queue fits within documented limits and the editorial deadline tolerates the job’s cadence. Use the per-database limit, five jobs and 120 seconds per execution as reference points. If WordPress and the queue share a database, measure its headroom. The first six months at a reduced rate do not shorten the commitment to six months. Check the advance payment and gross price associated with your country.

Authorize switchover when the signed POST reaches the intended origin and every tested delivery appears in the register with a single effect. Document response time, queue age and recovery method. If any attempt remains ambiguous, keep the old site available for diagnosis and prevent it from applying events. At the window’s end, record the last reconciled identifier and when the old origin stopped processing. A future redelivery must find the previous evidence.

• Check the POST route and durable recording with a test event.
• Compare attempts and register entries by identifier.
• Replay missed deliveries within the available window.
• Validate processing time and the unique draft before removing the old origin.

Further reading

• Read the Hostpoint profile
• Read the manitu profile
• Compare WordPress migration tools
• Download the incoming webhook test procedure (ZIP)