# Webhooks

Mark an inbound webhook route and it becomes a monitored service with its own uptime line.


Auto-detection sees the calls your app *makes*. A webhook is the reverse — a provider calling *you* — so mark the route explicitly and it becomes a monitored service with its own uptime line.

## Mark a webhook route

Wrap the handler with the `webhook()` middleware and give it the provider's name. It shows up branded in your System status.

```ts title="Express / Connect"
import { webhook } from '@everock/sdk/node';

app.post('/webhooks/stripe', webhook('stripe'), stripeHandler);
app.post('/webhooks/github', webhook('github'), githubHandler);
```

## How health is decided

- **Up** — your handler responds with a non-5xx status.
- **Down** — the handler responds 5xx, *or* hangs past the timeout.

The default timeout is 10 seconds. Raise it for slow handlers:

```ts title="custom timeout"
app.post('/webhooks/slow', webhook('slow', { timeoutMs: 30000 }), handler);
```


  Webhook services are passive — Everock never pings them. Health comes from the real inbound requests, so there's no extra traffic.



  An unhandled route failure can contribute both error evidence and webhook health. The observed result, request instrumentation, and [detection policy](/docs/features/errors) determine whether an incident is opened; the middleware does not independently guarantee a notification for every failure.