Custom HTTP checks
Define the endpoint assertion that only your product team knows how to make.
Define the endpoint assertion that only your product team knows how to make.
What this feature is for
Custom HTTP checks cover internal health routes, webhook receivers, signed callbacks, feature flags, and private product contracts that are not represented by a built-in integration. The important distinction is that PreFlight stores the observation alongside the app, release, provider, or customer path it belongs to. That context is what turns a signal into an operational decision.
Before you open it
A URL, method, optional headers or body, and an explicit assertion such as status, JSON field, response text, or latency threshold.
Use a real app in the workspace and start with the smallest useful scope. A narrow, representative check gives you a stronger baseline than connecting every environment and every provider at once.
Run the workflow
Create one assertion, run it manually against a safe environment, inspect the response evidence, then put it on a cadence after the result is trustworthy. Name it for the customer behavior it protects.
- Open the feature from the dashboard outcome hub.
- Choose the app and environment that match the decision you are making.
- Run or save the configuration, then wait for the evidence state to settle.
- Assign the next action to an owner before leaving the page.
Read the evidence
A custom result should show the request scope, observed response, assertion status, duration, and the last successful verification. A green state means the configured assertion passed at the recorded time. It does not claim that every unconfigured path is healthy. A warning is a useful lead; a failure should have a concrete owner and a verification run.
When the result is not healthy
Avoid assertions that depend on unstable timestamps, random identifiers, or a mutable demo record. If a check fails intermittently, narrow the assertion and investigate the underlying contract before increasing retries.
Do not erase the failed result after fixing the underlying system. Keep the history, rerun the check, and link the new passing evidence to the deployment or incident that caused the change. This gives the team a useful before-and-after record.
Use it with the rest of PreFlight
Use custom checks with Release desk to block risky changes and Uptime monitors to cover the same path continuously. Outcome hubs are deliberately connected: Audit finds risk, Deploy decides whether to promote, Health watches the running system, Revenue verifies the money path, Growth manages discoverability, and Trust publishes safe proof. Use the related links below to move between those decisions without losing context.