Usage

Organizations and Sandboxes are subject to limits on the number of resources (e.g. devices, applications and more) that are registered under that entity. Organizations may request increases to individual resource limits, though any such request may come at an additional cost. Sandbox limits cannot be adjusted.

Viewing Current Usage

Organization Usage

On this screen you will find comprehensive information about your organization’s usage, divided into payloads, notebooks, and resources.

Payloads

The payloads tab displays detailed information about your organization’s payload count usage.

The Billing Periods comparison method allows you to compare payload usage for different billing cycles. Available options are the current billing cycle, the previous billing cycle, or two billing cycles ago. The data type selector allows you to choose different data types to display: Billable Payloads (default), All Payloads, or Bytes.

If you wish to investigate your payload usage on a specific day and see per-hour usage, it is possible by selecting Daily as your Comparison Type. There you can choose any day within the last 93 days.

On the top right side, you will see total payload count sum within selected periods, as well as the organization’s monthly payload count limit.

The daily breakdown graph displays daily payload usage within selected billing periods. This graph will show hourly payload usage for the selected days in the UTC timezone if the Comparison Type is set to Daily.

The bottom graph displays cumulative payload usage for the selected period, along with projected cumulative usage for future dates (if an in-progress billing period is selected). Beneath the graph is a table displaying the organization’s applications and each application’s usage for the two selected billing periods.

Notebooks

The Notebooks tab displays detailed information about your organization’s notebook minute usage.

Available notebook minute usage comparison options are the current billing cycle, the previous billing cycle, or two billing cycles ago.

On the top right side, you will see total notebook minute sum within selected periods, as well as the organization’s monthly notebook minute limit.

The daily breakdown graph displays daily notebook minute usage within selected billing periods.

The bottom graph displays cumulative notebook usage for the selected period, along with projected cumulative usage for future dates (if an in-progress billing period is selected). Beneath the graph is a table displaying the organization’s applications and each application’s usage for the two selected billing periods.

Resources

On the Resources tab you will find comprehensive information about your organization’s resource usage and limits.

The Devices graph displays the daily device count over the last 30 days, along with the organization device limit.

On the right side, the All Resources list reveals your organization’s resource usage and limits.

On the bottom, the Resource Usage Per Application table is a perfect tool to explore the usage of each resource for each of the organization’s applications. The table allows to filter by application name, and sort by resource count.

Sandbox Usage

To see your Sandbox usage for the current period, navigate to the Usage link under the “My Account” section, on the “My Sandbox” overview page.

Usage Per Application

Though limits do not directly apply to applications, an application’s current usage can be viewed on the application’s overview page. This can, for example, help users determine which of their applications is generating large numbers of payloads and make adjustments to stay within usage limits.

Message Throttling

All message throughput is also subject to throttling and rate limits.

MQTT

WEGnology’s MQTT broker usage is subject to a few limits:

• 30 messages in a 15-second window per topic (or, on average, two messages per second)
• 300 messages in a 15-second window per client connection (or, on average, 20 messages per second)
• 300 new device connections in a 15-second window per application (or, on average, 20 new connections per second)
• 256KB per message

If you exceed the message rate limits, the device generating the messages is automatically disconnected, and will not be allowed to connect back to the broker for 30 seconds. If a device repeatedly exceeds these limits, the length of time the device is not allowed to connect will increase, up to a maximum of one hour.

Incoming and Outgoing Messages

An incoming message is typically a device reporting its state, and an outgoing message is usually a command being sent to a device. For example, if one command is sent to 50 devices, the command only counts as one outgoing message per connection against the message throttling limit, but it counts as 50 payloads against the payload limit.

However, incoming and outgoing messages can also come through custom MQTT topics, and in those cases, the topic rate limits are applied individually per direction. As in, a device may receive two messages per second and publish two messages per second on the same topic without exceeding the per-topic rate limit.

Events

Event creation is limited to 15 creations in a 15-second window per application (or, on average, one per second).

Webhooks

Webhook requests are limited to 100 calls in a 10-second window per webhook (or, on average, 10 per second). If you exceed this limit, the webhook will respond with a 429 “Over rate limit, request throttled” error.

Integrations

Integration messages are consumed at a rate of 200 messages in a 10-second window per integration (or, on average, 20 per second). If the integration is publishing messages at a rate higher than that, those messages will remain queued at the source (if the source supports that), and the messages will be consumed at the 20-per-second average rate.

The size of an individual integration message is also limited to 256KB.

Virtual Button Presses

Presses of a Virtual Button in an Application Workflow are limited to 100 calls in a 10-second window per Virtual Button (or, on average, 10 per second). This includes invocations by manual press, by Workflow Trigger Node executions, and by Input Controls Block executions.

Payload Limits

Depending on whether your application is owned by an Organization or a Sandbox, the behavior of your account once a payload limit is hit varies.

Note: For current Organization and Sandbox usage details, we also supply a message indicating if you are on pace to exceed that period’s payload limit. This is based on the number of payloads per second generated during the period extrapolated over the course of the entire period. Therefore, if your payload usage dramatically changes, it may take some time before the changes are reflected in the prognosis.

Organization Payload Limits

For Organizations, WEGnology will continue to accept payloads after you have reached your monthly limit. However, payloads over that limit come with an additional cost.

Sandbox Payload Limits

For Sandboxes, the number of payloads generated by your applications is a hard limit, in that once the limit has been exceeded for the period, any payloads sent to or generated by the platform will be rejected. If you reach this limit, your options are to:

• Create a new Organization and transfer some (or all) of your Sandbox resources into it.
• Transfer some (or all) of your Sandbox resources into an existing Organization for which you have administrator permissions.
• Adjust your applications so that they generate fewer payloads, and wait for the payload period to turn over. Your payloads will continue to be rejected until the new period begins.

Payload Types

We also supply a detailed breakdown of the number of payloads by type so that you can see where the majority of your payloads are accruing and make adjustments to your applications if necessary.

The following interactions count as a payload:

• A device reporting its state
• A command sent to a device
• Device connections to and disconnections from the WEGnology broker or via the REST API
• MQTT inbound and outbound messages on custom topics
• Incoming webhook requests
• Incoming experience endpoint requests
• Incoming application emails
• Incoming integration messages
• Resource Job iterations, completions, and timeouts
• Virtual Button Trigger presses, including those triggered by an Input Controls Block
• Application Workflow Timer Triggers (Edge Timer Triggers do not count towards payload limits)
• Device: Inactive Triggers
• Workflow Error Triggers

These interactions do NOT count as a payload:

• Event creations and modifications, or invocations of the Event Trigger
• Device creations and modifications, or invocations of the Device: Create Trigger
• Data requests, including those made by dashboards and device data exports
• Webhook replies in workflows
• Workflow runs triggered by another workflow through the Workflow Trigger Node
• Data table row insertions, deletions, edits, and queries, or invocations of the Data Table Trigger

Data Retention

Once data is older than the data retention limit, it is deleted. The data retention limit (or data TTL) for an application varies depending on your platform license (or if the application is within a user’s Sandbox). If you need longer term data retention, contact us for an enterprise plan with customized data retention limits.

The default sandbox data retention limit is 30 days. Your organization’s TTL can be found on the Organization Info screen. Each application’s TTL (as inherited from the application’s owner org / sandbox) is available on the Application Info screen.

The following resources are subject to your Organization or Sandbox data retention limits:

• Device state reports
• Device command logs
• Device connection logs
• Events
• Workflow storage (however, retention resets on both key read and write operations)

In addition, the following data is subject to custom limits, regardless of your Organization’s data retention limit:

• Workflow metrics (errors, run counts, and run time calculations) are stored for 30 days.
• Experience Endpoint request counts are stored for 30 days.
• Detailed payload count metrics are stored for 90 days.