tiqline is a process SLA monitoring tool: it turns events from Shopify and your own systems into one case per piece of work, gives every step a time limit and alerts you in Slack or by email when a step runs over.
Build or buy SLA monitoring: what a homemade setup really needs
Most teams can write a script that checks for late orders in an afternoon. The hard part comes later: keeping state for every case, handling branches, avoiding alert storms and explaining who changed a rule. This guide shows what each path costs and when a mix makes sense.
What building it yourself looks like
There are two common routes. The first is a scheduled job, for example a cron job or a database query every 15 minutes, that looks for orders whose status has not changed within a time window and posts to Slack and email. The second is an automation platform.
In Zapier, Delay by Zapier can pause a Zap for a set time, until a date, or after a queue, and the delay step does not count as a task. You can trigger a Zap on a new paid order, wait 24 hours, check the order again and send a message if it is still open. Filters and Paths for that check are part of the Professional plan and above.
In n8n, the Wait node pauses a workflow for an interval, until a set time, until a webhook call or until a form is submitted, and offloads the waiting execution to the database. Combined with the Shopify Trigger and an IF node you get the same pattern: start on an order, wait, check, alert.
What buying looks like
tiqline is built for exactly this job. You send events from Shopify or through the track API, describe the steps once, and set a time limit per step. Every order becomes a case. tiqline keeps the state, checks each deadline, groups stuck cases of one step into one incident and sends one alert to Slack or email with a link to the cases. The dashboard shows how many finished cases kept every time limit and how many are stuck right now.
What a homemade setup has to solve
The first version usually checks one step. The questions below appear in the weeks after.
- State per case: which step is each order in, and since when? A Wait step remembers one run. It does not give you a list of every waiting order.
- Duplicates: a webhook can arrive more than once. Your script needs to store each event only once, or you count an order twice.
- Changing a rule: in Shopify Flow, changing an active workflow makes waiting runs resume with the new version, and deactivating it stops the waiting runs. Similar trade-offs exist in any wait-based design.
- Branches: a refund path and a shipping path need different deadlines, and both can meet again later.
- Alert storms: 40 late orders should produce one message, not 40.
- Backfill: when you connect old data, orders that were late weeks ago should not all fire at once.
- Audit: who changed the time limit from 24 to 48 hours, and when?
Sources
Side by side
| Topic | tiqline | Homemade |
|---|---|---|
| Start | Connect Shopify or the track API, describe the steps | Write the job or the workflow |
| State per case | Kept for every case, with a timeline of events | Your own table or one waiting run per order |
| Duplicate events | Stored once | Your own deduplication |
| Grouping | One incident per stuck step | Your own logic |
| Old deadlines | Marked, no alert if older than 7 days | Your own logic |
| Rule changes | Apply at once, including running cases, and land in the audit log | Depends on the platform and your code |
| Upkeep | Run by tiqline | Your team |
When building fits
Build it when you have one or two checks, a developer who owns them and no plans to add more. Building is also the right call when the check needs data only your own systems have and the alert must do something specific, such as reopen a ticket. Zapier and n8n are strong here because they can act in other apps after the check; Zapier alone connects more than 9,000.
n8n's self-hosted Community Edition keeps everything on your own servers, which some teams need for policy reasons.
Sources
When buying fits
Buy when the number of steps, branches and people grows. The cost of a homemade check is not the first afternoon. It is the second year: a broken job nobody noticed, a deadline someone changed in code without telling anyone, or a Slack or email alert that went quiet because a token or password expired. tiqline puts the rules in one place and shows the stuck cases in a dashboard. Every plan includes the audit log, including Free, which records publishing a process, changing a time limit and connecting Slack or email.
Combining both
Use tiqline to watch and your automation platform to act. tiqline tells you that 12 orders are stuck at picking. A Zap or an n8n workflow can then do the follow-up you already automated, such as opening a ticket. tiqline itself sends alerts to Slack and email only, so the hand-off happens in those channels or in your own code.
An AI agent can set up the process for you. tiqline exposes its setup over MCP with OAuth sign-in, so an agent can create the ID fields, the process, the time limits and the alerts, and read the usage and the audit log.
Example: three checks become one process
All numbers in this example are made up for illustration. A shop runs three homemade checks: a Zap that waits 24 hours after payment and checks shipping, a nightly script that looks for refunds older than two days, and a Google Sheet for the warehouse. Each uses its own copy of the order data. One week the script fails quietly and 17 refunds wait four days.
In tiqline the same rules are one process: paid, then either fulfilled within 24 hours or refunded within 2 days, chosen by a branch on the event. The script and the sheet go away, the Zap stays for the follow-up. When the refund step overruns, one alert names the step and the number of waiting cases.
A quick cost check
Count the hours, not the licence. A homemade check needs someone to write it, someone to notice when it breaks, and someone to update it when the process changes. If one of those people leaves, the knowledge often goes with them. On the other side, tiqline bills by events, with 5,000 events a month on the Free plan and 50,000 on Standard for €49 excl. VAT a month. Every event is stored once, so a webhook that arrives twice does not count twice.
Limits of tiqline
tiqline does not run actions in other apps. It marks, groups and alerts, and alerts go to Slack and email. It does not explain why a case is stuck. It has no prebuilt connectors for warehouses or carriers, so those steps arrive through the track API with the order number. If you need a check that writes back into your systems, you still need code or an automation platform for that part.
Questions
Can I build SLA monitoring with Zapier?
Yes, with a trigger, Delay by Zapier and a filter. Each check is its own Zap. You keep the overview of all waiting orders and the grouping of alerts yourself.
Can I build it with n8n?
Yes. The Wait node pauses an execution and the IF node checks the state afterwards. Self-hosted, you also run and update n8n yourself.
What does a homemade setup usually miss?
A list of every open case with its deadline, one alert per stuck step instead of one per order, safe handling of old data and a record of who changed a rule.
Is buying more expensive than building?
The tiqline Free plan includes 5,000 events a month and Standard costs €49 excl. VAT a month for 50,000 events. Compare that with the hours your team spends keeping scripts and workflows running.
Can I move my existing rules?
You describe the steps and time limits in tiqline once. Changing a time limit applies at once, also to running cases.
Does tiqline replace my automation platform?
No. tiqline watches deadlines and alerts. Your automation platform keeps doing the actions in other apps.
Start for free
The Free plan includes 5,000 events a month.