Skip to content

chore: docs and website changes #341

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Apr 28, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -51,7 +51,7 @@ See the [Outpost Concepts](https://outpost.hookdeck.com/docs/concepts) for more
- **User portal**: Allow customers to view metrics, manage, debug, and observe their event destinations.
- **Automatic and manual retries**: Configure retry strategies for event destinations and manually trigger event delivery retries via the API or user portal.
- **Multi-tenant support**: Create multiple tenants on a single Outpost deployment.
- **User alerts**: Allow customers to manage event delivery alerts.
- **Delivery failure alerts**: Manage event delivery failure alerts.
- **OpenTelemetry**: OTel standardized traces, metrics, and logs.
- **Event destination types**: Out of the box support for Webhooks, Hookdeck Event Gateway, Amazon EventBridge, AWS SQS, AWS SNS. GCP Pub/Sub, RabbitMQ, and Kafka.
- **Webhook best practices**: Opt-out webhook best practices, such as headers for idempotency, timestamp and signature, and signature rotation.
Expand Down
2 changes: 1 addition & 1 deletion docs/pages/features.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ Outpost offers a range of features designed to provide a robust and flexible eve
- **[Event Topics and Topic-Based Subscriptions](./features/event-topics-and-subscriptions.mdx)**: Outpost supports the common publish and subscription (Pub/Sub) paradigm to ease adoption and integration into existing systems.
- **[Publish Events](./features/publish-events.mdx)**: Learn how events are published, either to a configured message bus queue or via the publish API endpoint.
- **[Event Delivery](./features/event-delivery.mdx)**: Understand how Outpost ensures reliable event delivery with support for various destination types, retries, and best practices.
- **[User Alerts (planned)](./features/user-alerts.mdx)**: Configure alerts for event delivery failures based on consecutive failures or failure rates.
- **[Delivery Failure Alerts](./features/delivery-failure-alerts.mdx)**: Configure alerts for event delivery failures based on consecutive failures.
- **[Tenant User Portal](./features/tenant-user-portal.mdx)**: Provide your tenants with an optional portal to configure destinations and inspect events.
- **[Configurable Log Levels](./features/configurable-log-levels.mdx)**: Control the verbosity of logs produced by Outpost services.
- **[OpenTelemetry](./features/opentelemetry.mdx)**: Monitor key performance metrics using OpenTelemetry integration.
Expand Down
34 changes: 34 additions & 0 deletions docs/pages/features/delivery-failure-alerts.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
---
title: Delivery Failure Alerts
---

Alerts are triggered when an event fails to deliver to a destination. Alerts are scoped per destination.

Destinations can be auto-disabled when the trigger is reached using the `ALERT_AUTO_DISABLE_DESTINATION` config.

Instead of implementing user-facing alerting, alerts are produced on a callback URL configured through the `ALERT_CALLBACK_URL` variable. The server does not respond with a `200` there will be an exponential backoff and log the failure. Authentication is handled using the Admin API Key via a bearer token.

It's your responsibility to format and deliver the alert to your tenant using your existing notification system.

## Consecutive failure alerts

`ALERT_CONSECUTIVE_FAILURE_COUNT` variable will alert when the consecutive failure count reaches 50%, 70%, 90% and 100%. At 100% the destination will be disabled if the config is enabled.

```json
{
"topic": "alert.consecutive-failure",
"timestamp": "2024-01-01T00:00:00Z",
"data": {
"max_consecutive_failures": 20,
"consecutive_failures": 5,
"will_disable": true,
"destination": DestinationObject,
"response": {
"status": "500",
"data": {
"some": "value"
}
}
}
}
```
59 changes: 0 additions & 59 deletions docs/pages/features/user-alerts.mdx

This file was deleted.

Loading