From 30ff01ad9e62ad95a6555c59108946e766614703 Mon Sep 17 00:00:00 2001 From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com> Date: Mon, 29 Sep 2025 22:08:28 +0200 Subject: [PATCH 01/14] Why isn't the channel filter regex in my integration rule working? --- src/pages/docs/platform/integrations/webhooks/index.mdx | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/pages/docs/platform/integrations/webhooks/index.mdx b/src/pages/docs/platform/integrations/webhooks/index.mdx index 6609175c30..9c27c3e17c 100644 --- a/src/pages/docs/platform/integrations/webhooks/index.mdx +++ b/src/pages/docs/platform/integrations/webhooks/index.mdx @@ -46,6 +46,15 @@ public:news:europe | `^public.*europe$` | Matches channels that start with `public` and end with `europe`. This includes only `public:news:europe`. | | `news` | Matches any channel name that includes the word `news`. This includes `public:news:americas` and `public:news:europe`. +### Common regex formatting issues + +When creating channel filter regex patterns, ensure you use proper regular expression syntax: + +- Correct: `public.*` - Matches "public" followed by any characters. +- Incorrect: `public*` - Matches "publi" followed by zero or more "c" characters. + +The `.*` pattern means "any character (.) zero or more times (*)", while `*` alone means "zero or more of the preceding character". + ## Event types You can configure webhooks to listen for the following event types: From 7e09e4ceb0992a348ac1fa3c303bf240ab23871d Mon Sep 17 00:00:00 2001 From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com> Date: Mon, 29 Sep 2025 22:32:39 +0200 Subject: [PATCH 02/14] How can I debug Event Functions? --- src/pages/docs/platform/integrations/index.mdx | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/pages/docs/platform/integrations/index.mdx b/src/pages/docs/platform/integrations/index.mdx index fb74498c1b..bda3f383d8 100644 --- a/src/pages/docs/platform/integrations/index.mdx +++ b/src/pages/docs/platform/integrations/index.mdx @@ -48,6 +48,18 @@ The following pre-built services can be configured: Whilst pub-sub channels broadcast messages to all subscribers, queues distribute work among consumers. Both patterns serve different use cases. For example, pub/sub is ideal for many users to receive realtime updates, while queues handle tasks like triggering emails efficiently. +## Debugging integrations + +If messages aren't reaching your endpoint, try these steps: + +First, check your integration setup in the Ably dashboard. Make sure the URL is correct and your channel filter matches the channels you're testing. + +Use the Test rule button to verify Ably can reach your endpoint. This tests the connection directly. + +If that works, publish a test message through the Dev Console to the channel your integration monitors. Check the Dev Console logs to see if the message was delivered. Errors can take up to 15 seconds to appear due to retry attempts. + +Common issues include regex patterns that don't match your channels, authentication problems, and endpoints that don't respond quickly enough. + ## Skip integrations + +Zapier can publish messages to Ably channels when other apps trigger events. This works well for connecting spreadsheets, forms, emails, and other services to your realtime channels. + +In Zapier, create a new Zap and choose your trigger (like a new spreadsheet row). Then add Ably as an action - you'll find "Publish Message" and "Publish Push Notification" options. You'll need to provide your API key from the Ably dashboard. + +Set up your message with the channel name and content. For push notifications, you can also add a title and body for the notification itself. + +Use Zapier's test button to check it works, then watch for messages in the Ably Dev Console. From e00f44c228c1dbc9c435cd4bda9d470e17eccd16 Mon Sep 17 00:00:00 2001 From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com> Date: Mon, 29 Sep 2025 23:27:15 +0200 Subject: [PATCH 05/14] Do Webhooks support ordered messages? --- .../docs/platform/integrations/webhooks/index.mdx | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/src/pages/docs/platform/integrations/webhooks/index.mdx b/src/pages/docs/platform/integrations/webhooks/index.mdx index 9c27c3e17c..8aab7c36a7 100644 --- a/src/pages/docs/platform/integrations/webhooks/index.mdx +++ b/src/pages/docs/platform/integrations/webhooks/index.mdx @@ -101,7 +101,15 @@ The backoff delay follows the formula: `delay = delay * sqrt(2)` where the initi The back off for consecutively failing requests will increase until it reaches 60s. All subsequent retries for failed requests will then be made at 60s intervals until a request is successful. The queue of events is retain for 5 minutes. If an event cannot be delivered within that time then events are discarded to prevent the queue from growing indefinitely. -### Batched event payloads +## Message ordering + +Webhooks don't always preserve message order the same way Ably channels do. It depends on how you've set up your webhook. + +With batched webhooks, messages stay in order as long as they're from the same publisher on the same channel. If a batch fails and gets retried, newer messages get included but they'll still be in the right order. Messages from different regions might arrive in separate batches, but that's fine since ordering is per-publisher anyway. + +Single request webhooks can't guarantee order. Each message fires off its own HTTP request, and there's no telling which one arrives first. If your server supports HTTP/2 though, you get ordering back because requests get pipelined down one connection. + +One gotcha: if you're publishing via REST (not realtime), you lose ordering guarantees even with batching on. That's because REST uses a connection pool where requests can finish out of order. Given the various potential combinations of enveloped, batched, and message sources, it's helpful to understand what to expect in different scenarios. From 1eab2a0a5fbba943019223a2572e84467fb604ef Mon Sep 17 00:00:00 2001 From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com> Date: Mon, 29 Sep 2025 23:33:21 +0200 Subject: [PATCH 06/14] Why are my Lambdas occasionally triggered more than once? --- src/pages/docs/platform/integrations/webhooks/lambda.mdx | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/pages/docs/platform/integrations/webhooks/lambda.mdx b/src/pages/docs/platform/integrations/webhooks/lambda.mdx index 0fe8827936..7c0e3db37a 100644 --- a/src/pages/docs/platform/integrations/webhooks/lambda.mdx +++ b/src/pages/docs/platform/integrations/webhooks/lambda.mdx @@ -105,3 +105,11 @@ Then ensure the checkbox for the policy is selected. 8. You don't need to add tags so click **Next: Review**. 9. Enter a suitable name for your role. 10. Click **Create Role**. + +## Lambda retry behavior + +Ably invokes Lambda functions asynchronously using the `event` invocation type. When a function returns an error, AWS Lambda automatically retries the execution up to two more times with delays between attempts (1 minute, then 2 minutes). + +This means your Lambda function might occasionally run multiple times for the same Ably event. Design your functions to handle this - either make them idempotent or check for duplicate processing. + +You can configure retry behavior in your AWS Lambda console under the function's asynchronous invocation settings. See the [AWS Lambda documentation](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-errors) for details on adjusting retry settings. From e4621a0700ba2a1cd41cc87065e68e0e36bcdc46 Mon Sep 17 00:00:00 2001 From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com> Date: Mon, 29 Sep 2025 23:36:22 +0200 Subject: [PATCH 07/14] Example AWS Lambda function, triggered by the Reactor, that publishes another message back to Ably --- .../platform/integrations/webhooks/lambda.mdx | 39 +++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/src/pages/docs/platform/integrations/webhooks/lambda.mdx b/src/pages/docs/platform/integrations/webhooks/lambda.mdx index 7c0e3db37a..8e7ae17bc1 100644 --- a/src/pages/docs/platform/integrations/webhooks/lambda.mdx +++ b/src/pages/docs/platform/integrations/webhooks/lambda.mdx @@ -113,3 +113,42 @@ Ably invokes Lambda functions asynchronously using the `event` invocation type. This means your Lambda function might occasionally run multiple times for the same Ably event. Design your functions to handle this - either make them idempotent or check for duplicate processing. You can configure retry behavior in your AWS Lambda console under the function's asynchronous invocation settings. See the [AWS Lambda documentation](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-errors) for details on adjusting retry settings. + +## Example Lambda function + +Here's a Lambda function that processes events from Ably and publishes a message back. You'll need to bundle this with the Ably client library when you upload it. + + +```javascript +'use strict'; + +const Ably = require('ably'); +const inspect = require('util').inspect; + +exports.handler = (event, context, callback) => { + console.log("Received event from Ably:", inspect(event)); + + // If you're using enveloped messages, the event has 'messages', 'appId', etc. + // Otherwise it's just the message data directly + const details = JSON.parse(event.messages[0].data); + + // Use the REST client - don't bother with websockets for one-off publishes + const ably = new Ably.Rest({ key: 'YOUR_API_KEY' }); + + // Publish to a different channel or you'll trigger this Lambda again! + const channel = ably.channels.get('lambda-responses'); + channel.publish('response', 'success', (err) => { + if(err) { + console.log("Error publishing back to Ably:", inspect(err)); + callback(err); + } else { + callback(null, 'success'); + } + }); +}; +``` + + +A few things to watch out for: use `Ably.Rest` instead of `Ably.Realtime` since you don't want to open websockets just for publishing. Make sure you publish to a different channel than the one triggering this Lambda, or you'll get stuck in a loop. And always call the callback inside the publish callback - otherwise your function might finish before the publish request goes out. + +There's a complete working example at [github.com/ably/example-lambda-function](https://github.com/ably/example-lambda-function) that you can download and deploy. From ee7cfdb65dc8139d8cc4f7f612aedc9eed15955b Mon Sep 17 00:00:00 2001 From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com> Date: Mon, 29 Sep 2025 23:39:55 +0200 Subject: [PATCH 08/14] How do I debug failed events from integration rules (queue, firehose, webhooks etc.)? --- src/pages/docs/platform/integrations/index.mdx | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/pages/docs/platform/integrations/index.mdx b/src/pages/docs/platform/integrations/index.mdx index bda3f383d8..adc08fb58d 100644 --- a/src/pages/docs/platform/integrations/index.mdx +++ b/src/pages/docs/platform/integrations/index.mdx @@ -60,6 +60,12 @@ If that works, publish a test message through the Dev Console to the channel you Common issues include regex patterns that don't match your channels, authentication problems, and endpoints that don't respond quickly enough. +### Integration failure logs + +When integrations fail (your endpoint returns an error), Ably logs the details to the `[meta]log` metachannel. These logs include the failure reason (like "POST returned HTTP status 500"), along with the rule ID, message ID, and channel name. + +You can see these failures live in the Dev Console, or use the history API to check past failures. You can also attach to the `[meta]log` channel with rewind to see the last 100 messages. + ## Skip integrations + +Can't connect to your queue? Here's what usually goes wrong. + +Use port 5671, not the standard AMQP port 5672. We only support TLS connections. + +Your API key needs queue subscribe permissions. Check this in your dashboard under App Keys if you're getting auth errors. + +We use AMQP 0.9.1. Older clients might not support this version. + +Don't declare queues or bind exchanges. Ably queues already exist - just connect to the queue name directly. + +Getting authentication errors? Your username is everything before the colon in your API key, password is everything after. + +Some clients struggle with our "shared" vhost. Make sure that's what you're using. + +Connection timing out? Try increasing your client timeout settings. + +No messages showing up? Check your queue rules and channel filters are set correctly. + ## Queue scalability Ably Queues are offered in two flavors; multi-tenanted and dedicated. From a35981ca321c856df56db0149c0da9df7d6d6065 Mon Sep 17 00:00:00 2001 From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com> Date: Mon, 29 Sep 2025 23:46:04 +0200 Subject: [PATCH 10/14] Are Ably Queues appropriate for Production? --- src/pages/docs/platform/integrations/queues.mdx | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/pages/docs/platform/integrations/queues.mdx b/src/pages/docs/platform/integrations/queues.mdx index 223bc1569e..5c555e45af 100644 --- a/src/pages/docs/platform/integrations/queues.mdx +++ b/src/pages/docs/platform/integrations/queues.mdx @@ -504,6 +504,16 @@ Connection timing out? Try increasing your client timeout settings. No messages showing up? Check your queue rules and channel filters are set correctly. +## Production considerations + +Ably Queues work well for testing and lower-volume applications, but have some limitations for production use at scale. + +The multi-tenanted queue service has periodic maintenance windows that can cause brief downtime. This is different from Ably's core platform which has stronger uptime guarantees. + +If you're building a production system that needs high throughput or can't handle maintenance downtime, consider using [streaming integrations](/docs/platform/integrations/streaming) instead. These let you pipe data into dedicated queue services like SQS, RabbitMQ, or Kinesis that you control. + +For enterprise customers with high-volume needs, we offer dedicated queue clusters that scale to millions of messages per second. + ## Queue scalability Ably Queues are offered in two flavors; multi-tenanted and dedicated. From 004b8d7c657845ee52d7696c387dc399ec26f066 Mon Sep 17 00:00:00 2001 From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com> Date: Mon, 29 Sep 2025 23:49:46 +0200 Subject: [PATCH 11/14] Can I make changes to a queue after it has been created? --- src/pages/docs/platform/integrations/queues.mdx | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/pages/docs/platform/integrations/queues.mdx b/src/pages/docs/platform/integrations/queues.mdx index 5c555e45af..1def84d34a 100644 --- a/src/pages/docs/platform/integrations/queues.mdx +++ b/src/pages/docs/platform/integrations/queues.mdx @@ -78,6 +78,20 @@ The following steps explain how to provision an Ably Queue: A [Dead Letter Queue](#deadletter) is automatically created. It stores messages that fail to be processed, or expire. +### Modifying queues + +Queues can't be changed after creation - they're immutable. If you need different settings, you'll need to create a new queue and migrate. + +Here's how to switch to a new queue: + +1. Create a new queue with your desired settings +2. Update your consumers to subscribe to both the old and new queues +3. Change your queue rules to route messages to the new queue +4. Wait for the old queue to drain completely +5. Delete the old queue once empty + +This process ensures no message loss during the transition. + ### Configure a Queue rule After you provision a Queue, create one or more Queue rules to republish messages, presence events, or channel events from channels into that queue. From 18d7d7dd6181bb1a633e1182eabcafbe4646a705 Mon Sep 17 00:00:00 2001 From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com> Date: Mon, 29 Sep 2025 23:53:00 +0200 Subject: [PATCH 12/14] I upgraded but my queue still has the old message limits? --- src/pages/docs/platform/integrations/queues.mdx | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/pages/docs/platform/integrations/queues.mdx b/src/pages/docs/platform/integrations/queues.mdx index 1def84d34a..6376b10747 100644 --- a/src/pages/docs/platform/integrations/queues.mdx +++ b/src/pages/docs/platform/integrations/queues.mdx @@ -82,6 +82,8 @@ A [Dead Letter Queue](#deadletter) is automatically created. It stores messages Queues can't be changed after creation - they're immutable. If you need different settings, you'll need to create a new queue and migrate. +This includes limits like TTL and max length. Even if you upgrade your Ably account, existing queues keep the limits they were created with. You'll need to replace them to get the higher limits from your new plan. + Here's how to switch to a new queue: 1. Create a new queue with your desired settings From a8e42447fe70fe2c84da051d690280eb23784841 Mon Sep 17 00:00:00 2001 From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com> Date: Tue, 30 Sep 2025 00:00:28 +0200 Subject: [PATCH 13/14] Ably Datadog integration --- .../platform/integrations/streaming/datadog.mdx | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/pages/docs/platform/integrations/streaming/datadog.mdx b/src/pages/docs/platform/integrations/streaming/datadog.mdx index 9f4578449d..1929cbd4fb 100644 --- a/src/pages/docs/platform/integrations/streaming/datadog.mdx +++ b/src/pages/docs/platform/integrations/streaming/datadog.mdx @@ -28,6 +28,20 @@ The following steps setup the Datadog integration: 6. Datadog authorization page, authorize Ably using **OAuth** to grant access. The required authorization scope is: `api_keys_write`. 7. After completing authorization, you will be redirected to the **Ably dashboard**, and the process is complete. +## Troubleshooting integration states + +Having trouble connecting? Here's what usually goes wrong. + +Stuck on "Connecting"? Your connection probably got interrupted. Contact support if it won't budge. + +Getting "Connection failed"? Same deal - reach out to support. + +"API key with this name already exists"? You've already got that key in Datadog. Delete the old one first. + +"Forbidden" or permission errors? You need Datadog Admin permissions to set this up. + +Once it's working, hit "See Dashboard" in Ably to jump over to Datadog. Your data shows up every minute. + ## Remove access Removing access disconnects Ably from Datadog, stopping data transmission and revoking authorization. Follow the steps remove the Ably and Datadog integration using either platform. From 3b57a17aacb1c2aae9ebd8b70d29bb44dfafd9f9 Mon Sep 17 00:00:00 2001 From: Francis Roberts <111994975+franrob-projects@users.noreply.github.com> Date: Tue, 30 Sep 2025 15:02:02 +0200 Subject: [PATCH 14/14] Tidy up commit --- .../integrations/inbound/webhooks.mdx | 8 ++-- .../docs/platform/integrations/index.mdx | 14 +++---- .../docs/platform/integrations/queues.mdx | 38 +++++++++---------- .../integrations/streaming/datadog.mdx | 15 +++----- .../platform/integrations/webhooks/index.mdx | 8 ++-- .../platform/integrations/webhooks/lambda.mdx | 10 ++--- src/pages/docs/platform/pricing/limits.mdx | 4 +- 7 files changed, 47 insertions(+), 50 deletions(-) diff --git a/src/pages/docs/platform/integrations/inbound/webhooks.mdx b/src/pages/docs/platform/integrations/inbound/webhooks.mdx index 9a14880e0c..fe7da8c4b3 100644 --- a/src/pages/docs/platform/integrations/inbound/webhooks.mdx +++ b/src/pages/docs/platform/integrations/inbound/webhooks.mdx @@ -98,10 +98,10 @@ To ensure that publishes are [idempotent](/docs/pub-sub/advanced#idempotency), a ## Publishing from Zapier -Zapier can publish messages to Ably channels when other apps trigger events. This works well for connecting spreadsheets, forms, emails, and other services to your realtime channels. +Zapier can publish messages to Ably channels when other apps trigger events. This connects spreadsheets, forms, emails, and other services to realtime channels. -In Zapier, create a new Zap and choose your trigger (like a new spreadsheet row). Then add Ably as an action - you'll find "Publish Message" and "Publish Push Notification" options. You'll need to provide your API key from the Ably dashboard. +In Zapier, create a new Zap and choose a trigger (like a new spreadsheet row). Add Ably as an action with "Publish Message" and "Publish Push Notification" options. Provide the API key from the Ably dashboard. -Set up your message with the channel name and content. For push notifications, you can also add a title and body for the notification itself. +Set up the message with the channel name and content. For push notifications, add a title and body for the notification itself. -Use Zapier's test button to check it works, then watch for messages in the Ably Dev Console. +Use Zapier's test button to verify functionality, then watch for messages in the Ably Dev Console. diff --git a/src/pages/docs/platform/integrations/index.mdx b/src/pages/docs/platform/integrations/index.mdx index adc08fb58d..3bf81b60d0 100644 --- a/src/pages/docs/platform/integrations/index.mdx +++ b/src/pages/docs/platform/integrations/index.mdx @@ -50,21 +50,21 @@ Whilst pub-sub channels broadcast messages to all subscribers, queues distribute ## Debugging integrations -If messages aren't reaching your endpoint, try these steps: +If messages are not reaching the endpoint, follow these steps: -First, check your integration setup in the Ably dashboard. Make sure the URL is correct and your channel filter matches the channels you're testing. +1. Check the integration setup in the Ably dashboard. Verify the URL is correct and the channel filter matches the channels being tested. -Use the Test rule button to verify Ably can reach your endpoint. This tests the connection directly. +2. Use the Test rule button to verify Ably can reach the endpoint. This tests the connection directly. -If that works, publish a test message through the Dev Console to the channel your integration monitors. Check the Dev Console logs to see if the message was delivered. Errors can take up to 15 seconds to appear due to retry attempts. +3. If the connection test succeeds, publish a test message through the Dev Console to the channel the integration monitors. Check the Dev Console logs to see if the message was delivered. Errors can take up to 15 seconds to appear due to retry attempts. -Common issues include regex patterns that don't match your channels, authentication problems, and endpoints that don't respond quickly enough. +Common issues include regex patterns that do not match channels, authentication problems, and endpoints that do not respond quickly enough. ### Integration failure logs -When integrations fail (your endpoint returns an error), Ably logs the details to the `[meta]log` metachannel. These logs include the failure reason (like "POST returned HTTP status 500"), along with the rule ID, message ID, and channel name. +When integrations fail (endpoint returns an error), Ably logs the details to the `[meta]log` metachannel. These logs include the failure reason (such as "POST returned HTTP status 500"), along with the rule ID, message ID, and channel name. -You can see these failures live in the Dev Console, or use the history API to check past failures. You can also attach to the `[meta]log` channel with rewind to see the last 100 messages. +View these failures live in the Dev Console, or use the history API to check past failures. Attach to the `[meta]log` channel with rewind to see the last 100 messages. ## Skip integrations -Queues can't be changed after creation - they're immutable. If you need different settings, you'll need to create a new queue and migrate. +Queues cannot be modified after creation - they are immutable. Different settings require creating a new queue and migrating. -This includes limits like TTL and max length. Even if you upgrade your Ably account, existing queues keep the limits they were created with. You'll need to replace them to get the higher limits from your new plan. +This includes limits like TTL and max length. Even after upgrading an Ably account, existing queues retain the limits they were created with. Replacement is required to get the higher limits from a new plan. -Here's how to switch to a new queue: +Steps to switch to a new queue: -1. Create a new queue with your desired settings -2. Update your consumers to subscribe to both the old and new queues -3. Change your queue rules to route messages to the new queue +1. Create a new queue with the desired settings +2. Update consumers to subscribe to both the old and new queues +3. Change queue rules to route messages to the new queue 4. Wait for the old queue to drain completely 5. Delete the old queue once empty @@ -502,33 +502,33 @@ Ably names the Dead Letter Queue using the reserved format `APPID:deadletter`, w ## Troubleshooting queue connections -Can't connect to your queue? Here's what usually goes wrong. +Common queue connection issues: -Use port 5671, not the standard AMQP port 5672. We only support TLS connections. +**Port Configuration**: Use port 5671, not the standard AMQP port 5672. Only TLS connections are supported. -Your API key needs queue subscribe permissions. Check this in your dashboard under App Keys if you're getting auth errors. +**API Key Permissions**: The API key needs queue subscribe permissions. Check this in the dashboard under App Keys for authentication errors. -We use AMQP 0.9.1. Older clients might not support this version. +**AMQP Version**: AMQP 0.9.1 is required. Older clients might not support this version. -Don't declare queues or bind exchanges. Ably queues already exist - just connect to the queue name directly. +**Queue Declaration**: Do not declare queues or bind exchanges. Ably queues already exist - connect to the queue name directly. -Getting authentication errors? Your username is everything before the colon in your API key, password is everything after. +**Authentication Format**: The username is everything before the colon in the API key, password is everything after. -Some clients struggle with our "shared" vhost. Make sure that's what you're using. +**Virtual Host**: Use the "shared" vhost. Some clients may have difficulty with this configuration. -Connection timing out? Try increasing your client timeout settings. +**Connection Timeout**: Increase client timeout settings if connections are timing out. -No messages showing up? Check your queue rules and channel filters are set correctly. +**Message Delivery**: Verify queue rules and channel filters are configured correctly if no messages appear. ## Production considerations -Ably Queues work well for testing and lower-volume applications, but have some limitations for production use at scale. +Ably Queues work well for testing and lower-volume applications, but have limitations for production use at scale. -The multi-tenanted queue service has periodic maintenance windows that can cause brief downtime. This is different from Ably's core platform which has stronger uptime guarantees. +The multi-tenanted queue service has periodic maintenance windows that can cause brief downtime. This differs from Ably's core platform which has stronger uptime guarantees. -If you're building a production system that needs high throughput or can't handle maintenance downtime, consider using [streaming integrations](/docs/platform/integrations/streaming) instead. These let you pipe data into dedicated queue services like SQS, RabbitMQ, or Kinesis that you control. +For production systems requiring high throughput or that cannot handle maintenance downtime, consider using [streaming integrations](/docs/platform/integrations/streaming) instead. These allow data to be piped into dedicated queue services like SQS, RabbitMQ, or Kinesis under direct control. -For enterprise customers with high-volume needs, we offer dedicated queue clusters that scale to millions of messages per second. +For enterprise customers with high-volume needs, dedicated queue clusters are available that scale to millions of messages per second. ## Queue scalability diff --git a/src/pages/docs/platform/integrations/streaming/datadog.mdx b/src/pages/docs/platform/integrations/streaming/datadog.mdx index 1929cbd4fb..f4641dd57d 100644 --- a/src/pages/docs/platform/integrations/streaming/datadog.mdx +++ b/src/pages/docs/platform/integrations/streaming/datadog.mdx @@ -30,17 +30,14 @@ The following steps setup the Datadog integration: ## Troubleshooting integration states -Having trouble connecting? Here's what usually goes wrong. +Common connection issues: -Stuck on "Connecting"? Your connection probably got interrupted. Contact support if it won't budge. +* Stuck on "Connecting": Connection was interrupted. Contact support if the status does not change. +* Getting "Connection failed": Contact support for assistance. +* "API key with this name already exists": The key already exists in Datadog. Delete the existing key first. +* "Forbidden" or permission errors: Datadog Admin permissions are required to set up this integration. -Getting "Connection failed"? Same deal - reach out to support. - -"API key with this name already exists"? You've already got that key in Datadog. Delete the old one first. - -"Forbidden" or permission errors? You need Datadog Admin permissions to set this up. - -Once it's working, hit "See Dashboard" in Ably to jump over to Datadog. Your data shows up every minute. +After successful setup, select "See Dashboard" in Ably to navigate to Datadog. Data appears every minute. ## Remove access diff --git a/src/pages/docs/platform/integrations/webhooks/index.mdx b/src/pages/docs/platform/integrations/webhooks/index.mdx index 8aab7c36a7..5f376019b9 100644 --- a/src/pages/docs/platform/integrations/webhooks/index.mdx +++ b/src/pages/docs/platform/integrations/webhooks/index.mdx @@ -103,13 +103,13 @@ The back off for consecutively failing requests will increase until it reaches 6 ## Message ordering -Webhooks don't always preserve message order the same way Ably channels do. It depends on how you've set up your webhook. +Webhooks do not always preserve message order the same way Ably channels do. This depends on the webhook configuration. -With batched webhooks, messages stay in order as long as they're from the same publisher on the same channel. If a batch fails and gets retried, newer messages get included but they'll still be in the right order. Messages from different regions might arrive in separate batches, but that's fine since ordering is per-publisher anyway. +Batched webhooks preserve message order when messages are from the same publisher on the same channel. If a batch fails and gets retried, newer messages are included while maintaining correct order. Messages from different regions might arrive in separate batches, maintaining per-publisher ordering. -Single request webhooks can't guarantee order. Each message fires off its own HTTP request, and there's no telling which one arrives first. If your server supports HTTP/2 though, you get ordering back because requests get pipelined down one connection. +Single request webhooks cannot guarantee order. Each message triggers its own HTTP request, and arrival order is not predictable. HTTP/2 server support can restore ordering through request pipelining over a single connection. -One gotcha: if you're publishing via REST (not realtime), you lose ordering guarantees even with batching on. That's because REST uses a connection pool where requests can finish out of order. +Publishing via REST (not realtime) removes ordering guarantees even with batching enabled, as REST uses a connection pool where requests can complete out of order. Given the various potential combinations of enveloped, batched, and message sources, it's helpful to understand what to expect in different scenarios. diff --git a/src/pages/docs/platform/integrations/webhooks/lambda.mdx b/src/pages/docs/platform/integrations/webhooks/lambda.mdx index 8e7ae17bc1..a9630e9db6 100644 --- a/src/pages/docs/platform/integrations/webhooks/lambda.mdx +++ b/src/pages/docs/platform/integrations/webhooks/lambda.mdx @@ -110,13 +110,13 @@ Then ensure the checkbox for the policy is selected. Ably invokes Lambda functions asynchronously using the `event` invocation type. When a function returns an error, AWS Lambda automatically retries the execution up to two more times with delays between attempts (1 minute, then 2 minutes). -This means your Lambda function might occasionally run multiple times for the same Ably event. Design your functions to handle this - either make them idempotent or check for duplicate processing. +Lambda functions might run multiple times for the same Ably event. Design functions to handle this by making them idempotent or checking for duplicate processing. -You can configure retry behavior in your AWS Lambda console under the function's asynchronous invocation settings. See the [AWS Lambda documentation](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-errors) for details on adjusting retry settings. +Configure retry behavior in the AWS Lambda console under the function's asynchronous invocation settings. See the [AWS Lambda documentation](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-errors) for details on adjusting retry settings. ## Example Lambda function -Here's a Lambda function that processes events from Ably and publishes a message back. You'll need to bundle this with the Ably client library when you upload it. +The following Lambda function processes events from Ably and publishes a message back. Bundle this with the Ably client library when uploading. ```javascript @@ -149,6 +149,6 @@ exports.handler = (event, context, callback) => { ``` -A few things to watch out for: use `Ably.Rest` instead of `Ably.Realtime` since you don't want to open websockets just for publishing. Make sure you publish to a different channel than the one triggering this Lambda, or you'll get stuck in a loop. And always call the callback inside the publish callback - otherwise your function might finish before the publish request goes out. +Important considerations: Use `Ably.Rest` instead of `Ably.Realtime` to avoid opening websockets for publishing. Publish to a different channel than the one triggering this Lambda to prevent loops. Always call the callback inside the publish callback to prevent the function from finishing before the publish request completes. -There's a complete working example at [github.com/ably/example-lambda-function](https://github.com/ably/example-lambda-function) that you can download and deploy. +A complete working example is available at [github.com/ably/example-lambda-function](https://github.com/ably/example-lambda-function) for download and deployment. diff --git a/src/pages/docs/platform/pricing/limits.mdx b/src/pages/docs/platform/pricing/limits.mdx index 9ba6ded16d..ac56c7fbe2 100644 --- a/src/pages/docs/platform/pricing/limits.mdx +++ b/src/pages/docs/platform/pricing/limits.mdx @@ -107,9 +107,9 @@ Integration limits relate to the rate and concurrency of [webhooks](/docs/platfo ### Why integration rate limits exist -Rate limits prevent issues when there's a mismatch between your channel message rate and your endpoint's processing capacity. Without limits, messages could queue up invisibly, creating backlogs you can't monitor or manage. +Rate limits prevent issues when there is a mismatch between channel message rate and endpoint processing capacity. Without limits, messages could queue up invisibly, creating backlogs that cannot be monitored or managed. -For high-volume scenarios, use an intermediary queue like [AWS Kinesis](/docs/platform/integrations/streaming/kinesis) instead of direct webhook delivery. This provides better visibility into message backlogs and allows you to batch process messages or discard stale ones. +For high-volume scenarios, use an intermediary queue like [AWS Kinesis](/docs/platform/integrations/streaming/kinesis) instead of direct webhook delivery. This provides better visibility into message backlogs and allows batch processing of messages or discarding of stale ones. | Integration limit | Free | Standard | Pro | Enterprise | | ----------------- | ---- | -------- | --- | ---------- |