Slack Alerts

Slack alerts post a message to a Slack channel of your choosing when a product runs out of stock at a location — and one more message when stock comes back. They are switched off until someone on your account adds a Slack destination, and they are included on the plan you are already on — there is no add-on to buy.

Slack alerts are available on Shared and Dedicated instances alike. What decides is where your instance actually runs, not the plan name. If we are moving your instance between tiers, alerts keep running on the shared fleet until the move and resume on the new server once the move is complete; the daily check may not run on the days the move is in progress.

The short version#

  • Stock-outs only. A message is posted when a product that has a minimum level set at a location drops to zero quantity on hand there. Nothing else is posted. A product that is below its minimum but not at zero, and a lot that is close to expiring, are never posted to Slack — those stay in the daily stock alert email. If a product has no minimum level at that location, it is never checked, however low it gets.
  • From the same daily check as the email. We take one picture of your stock each day, in your instance's timezone, and messages are posted from that picture. This is not real time: a product that runs out at noon is not posted until the next daily check sees it.
  • One message per product and location, then one "stock returned" message. If the product is still at zero the next day, nothing more is posted. When the next daily check sees stock again, we post a single Stock returned message for it. If the same product runs out again later, that is a new message.
  • At most 50 new stock-outs per destination per day. If more products than that run out on one day, we post 50 and then one extra message saying how many more there are, with the true total.
  • The webhook must come from a Slack app. Legacy custom-integration webhooks and GovSlack are not supported; the URL's host must be hooks.slack.com.
  • Anyone on your account can add, change or remove a destination, and can send a test — and a test pages nobody; it posts one short message marked [TEST].

Setting it up in Slack#

You need three things on the Slack side:

  1. A Slack app in your workspace. Go to api.slack.com/apps, choose Create New App, and create it in the workspace whose channel should receive the alerts.
  2. Incoming Webhooks turned on for that app. In the app's settings, open Incoming Webhooks and switch it on.
  3. A webhook added to the workspace. Choose Add New Webhook to Workspace and pick the channel it should post to. Slack gives you a URL starting with https://hooks.slack.com/. That URL is the whole secret — anyone holding it can post to that channel — so treat it like a password.

The channel is chosen in Slack when the webhook is created, not in Lift. To post to a different channel, create another webhook in the same app for that channel and paste its URL.

Adding the destination#

  1. Go to Integrations in the portal sidebar, then the Destinations tab.
  2. Open Slack and choose Add Slack destination.
  3. Give it a name you will recognise, like "#warehouse-alerts".
  4. Paste the webhook URL from your Slack app.
  5. Save.

The webhook URL is entered once and never shown again. We store it encrypted, and there is no way to read it back — not in the portal, not through support. After saving, the panel shows only the host (hooks.slack.com). To change the URL, open the destination with Edit and paste a new one; to keep it, leave the field blank.

You can have up to 5 Slack destinations on an instance, each with its own webhook — every stock-out goes to all of them. A Slack destination and a PagerDuty destination can sit side by side on the same instance; the Destinations page lists both kinds together.

Anyone on your account can open this panel and change these settings — add a destination, change its URL, switch it off, remove it, and send a test. It is a shared team surface, not an owner-only control. Our support team can see your destinations (the name and the host, never the URL) but can never change them.

Sending a test#

Once a destination is saved, its edit dialog has a Send test message button, and the card on the Destinations page has one too. The test posts one short message marked [TEST] to the channel, saying that stock alerts for your instance are connected and that nothing is out of stock. It does not page anyone — a Slack channel is not an on-call rotation — so there is nothing to put in a maintenance window first.

Tests are rate-limited: one test per destination every 5 minutes. Pressing the button again inside that window sends nothing and tells you so — it is not a sign that the URL is wrong.

What a message looks like#

The headline is "Out of stock: product at location". The message carries the product and its code, the location, the quantity on hand (zero), the minimum level you set, the date of the check that found it, and your instance's name with a link to it. A footer line reads "one message per product and location; a 'stock returned' message follows when the next daily check sees stock."

If the daily cap is reached, the extra message is headed "N more products out of stock at your instance" and names the real numbers, pointing you at the daily email and your instance's reorder report for the full list.

When stock comes back, the message is headed "Stock returned: product at location" and says the out-of-stock alert for it is closed.

When the messages stop#

There is nothing to close in Slack. The only follow-up we ever post is the Stock returned message, when the next daily check sees a quantity above zero for that product at that location. Every other reason we stop tracking a stock-out is silent — nothing is posted, and the channel simply stops hearing about that product:

  • The product is no longer tracked. The minimum level was removed, or the product or location is gone.
  • We could not check for three days running. If your instance has had no usable daily check for three consecutive days — it was suspended, being rebuilt, or the data could not be read — we stop tracking the stock-out rather than hold it open with nothing behind it.
  • You changed or removed the destination. See the next section.
  • Your instance was suspended or closed.

Replacing the webhook URL or removing the destination#

Replacing the URL posts nothing to the old webhook and nothing to the new one to confirm the change: messages go to the new webhook from the next daily check. Leaving the field blank keeps the URL you already saved.

Removing the destination stops every message to that channel from the next daily check, and nothing is posted to say so. Unlike PagerDuty, nothing is closed anywhere when you change or remove a Slack destination, because there is nothing to close in a channel.

When Slack stops accepting our requests#

If Slack refuses a message — the webhook was deleted, the app was removed from the workspace, the channel was archived — and it happens three times in a row, we switch the destination off and stop sending to it. The panel says so. A Slack outage or rate limit does not count: those are retried and never switch anything off.

To switch it back on, check that the webhook still exists in your Slack app, then open the destination with Edit and save its URL again — pasting the same URL is enough.

What is not included#

  • Below-minimum and nearing-expiry are not posted. They are in the daily stock alert email only. Slack is for the one thing that stops work: a product at zero.
  • No daily or weekly digest to Slack.
  • Orders and shipments are not posted to Slack. Those are webhook events, delivered to an endpoint you own, not to a channel.
  • Not a webhook event. Stock-outs are not available through the webhooks API; this is a notification channel of its own.
  • Microsoft Teams destinations are coming soon — we are building them, they are not available yet, and we give no date.
  • Stock alerts — the daily email, which is where below-minimum and expiring stock are reported.
  • PagerDuty alerts — the same stock-outs as incidents on your on-call service.
  • Integrations overview — what is available today and what is coming.