Stock-outs in PagerDuty: paging on-call when stock runs out

PagerDuty is usually associated with servers going down. But a hospital pharmacy or a warehouse with an on-call rota has the same need for a different kind of failure: a product nobody can work without has run out. OpenBoxes Lift can open a PagerDuty incident when that happens. This article is about the decisions around it: whether a stock-out should page anyone at all, how to test the connection without waking someone up, and how severity and urgency interact. The setup reference lives in PagerDuty alerts.

What Lift sends, in short#

When a product that has a minimum level set at a location drops to zero quantity on hand there, Lift opens an incident on your PagerDuty service, and resolves it when stock comes back.

Lift checks your stock once a day, in your instance's timezone, and opens and closes incidents from that daily picture. A product that runs out at noon is not an incident until the next daily check sees it. This is a daily safety net for stock-outs, not an instant alarm.

A few rules shape what your on-call will see:

• Stock-outs only. Products below their minimum but not at zero, and lots nearing expiry, never open an incident. They stay in the daily stock alert email.
• Only products with a minimum level are checked. A product with no minimum at a location is never checked there, however low it gets.
• One incident per product and location. A product still at zero the next day does not open a second one.
• At most 50 new incidents per destination per day. Past that, one extra incident gives the true total.

PagerDuty alerts are included on the plan you are already on, with no add-on to buy, on Shared and Dedicated instances alike.

Should a stock-out page anyone?#

Because the check runs once a day, an incident arrives after that day's check, whatever time the product actually ran out. Before you connect it to a rota that wakes people up, ask a few questions:

• Who can act on it? An incident that nobody can do anything about until the store opens is a notification, not a page.
• Which products justify it? Set minimum levels deliberately. Every product with a minimum can open an incident when it hits zero, so a long list of minimums means a long list of possible incidents.
• How loud should it be? That is a PagerDuty setting, not a Lift one (see below).

One cautious way to start is to point the destination at a service whose escalation policy notifies a store manager, and widen it to a rota only once you trust your minimum levels.

Connecting it#

On the PagerDuty side you need a service with an Events API v2 integration, which gives you the integration key, and an escalation policy that decides who is notified. In the portal, go to Integrations, then Destinations, then PagerDuty, choose the region your account is in (United States or European Union), paste the key and save. The key is stored encrypted and never shown again. The PagerDuty alerts article has the step-by-step version.

Testing without waking anyone#

This is the step most people get wrong. The Send test incident button opens a real [TEST] incident at severity info and resolves it straight away. Neither of those things stops PagerDuty from notifying whoever is on call for that service right now.

To test quietly, do one of these first:

• Put the service in a maintenance window. In PagerDuty's words: "While a service is in a maintenance window, its integrations are disabled and no new incidents will trigger."
• Point the destination at a test service whose escalation policy notifies only you (or a schedule with nobody on call).
• Add an Event Orchestration rule that suppresses events for the service.

Tests are limited to one per destination every 5 minutes. A second press inside that window sends nothing and says so; it does not mean the key is wrong.

Severity and urgency#

Every stock-out incident is sent at severity warning, never error or critical. A test is info.

How loudly PagerDuty notifies your on-call is governed by your service's urgency settings, not by Lift. A PagerDuty service defaults to high urgency whatever severity it receives. Severity only lowers urgency if you have turned on Dynamic Notifications, which maps warning and info to low urgency. If you want stock-outs to be quieter than a server outage, that is where to set it, or route them to a service of their own with a gentler escalation policy.

Living with it day to day#

• What an incident says. The title reads "Out of stock: product at location (your instance)", and the incident links to your instance in OpenBoxes.
• How incidents close. Mostly by stock coming back, seen by the next daily check. An incident also closes when the product is no longer tracked, when there has been no usable daily check for three days, or when the instance is suspended or closed. It is never closed just because it is old.
• Changing the key. Replacing the integration key, changing the region, switching the destination off or removing it first resolves the incidents that destination has open. If you rotate a key during a real stock-out, your on-call will see those incidents close, and any product still at zero opens a new incident under the new key within about an hour.
• When PagerDuty refuses events. After three refusals in a row (a wrong key, a deleted service, the wrong region), Lift switches the destination off and says so in the panel. Saving the key again switches it back on.

Each of these is covered in full in PagerDuty alerts.

Summary#

• Decide first whether a stock-out should page anyone, and which products deserve a minimum level.
• A test pages whoever is on call unless you use a maintenance window, a quiet test service or a suppression rule.
• Stock-outs arrive from a once-a-day check at severity warning; how loud they are is your PagerDuty urgency setting.