Stork Delivery
Integration monitoring that operations can use
Show which business records are waiting, why they are stuck, and who can resolve them, alongside the technical health checks.
The problem: healthy services can conceal stalled business work
An integration dashboard says every service is online. Customer service is looking at an order that has not reached the warehouse.
Both observations can be true. A service can respond normally while the business workflow is stalled.
Operations needs a view of the work, not just a view of the servers.
A practical approach
Define what should have happened
Choose a few important relationships between events. An accepted order should eventually have a downstream fulfillment reference. A completed shipment should eventually have the appropriate customer-facing update.
Define a reasonable time window for each relationship. The expected delay may differ between a scheduled batch and an event-driven integration.
A record outside that window becomes something the team can investigate. It should be possible to tell whether it is waiting normally, retrying, or blocked on a problem.
Put context beside the alert
A useful operational view might include:
- The business record and its source system.
- The last confirmed successful step.
- The next expected step and how long it has been waiting.
- The latest error category, with sensitive details restricted.
- The responsible team and permitted recovery action.
Do not require an operations user to understand an internal stack trace before deciding what to do. Keep technical detail available to the people who need it without making it the only explanation.
Separate a notification from a page
Some conditions need prompt intervention. Others belong in a work queue or a routine review. If every retry wakes someone up, meaningful failures become harder to distinguish.
Google's SRE guidance on monitoring emphasizes actionable monitoring and attention to user-visible symptoms. Apply that thinking to the business process: alert on conditions that require a response, with a clear reason and owner.
Make recovery controlled
A replay button should show what it will retry and protect against duplicate effects. A manual override should record who made the change and why.
After recovery, verify the downstream result. Clearing an error message is not the same as completing the order.
Keep a small set of reconciliations as a second check. They can catch missing events that never entered the monitored queue at all.
When systems integration is operating well, the team can answer three questions quickly: what is stuck, what it affects, and what happens next. That is a useful dashboard.
The result: a queue operations can use to recover work
Pick one stalled-order condition and define its expected time window. Create a controlled test case, verify that it appears with an owner and a permitted action, and confirm recovery in the destination system. Check that the alert closes only when the business condition is resolved. Begin with this full path before adding more dashboard panels or notifications.