Business Flow Monitoring: Signup to Activation
A user stuck between verified email and working account will not file a ticket. They will assume the product is broken and leave.
Onboarding failures are uniquely expensive because the person affected has no relationship with you yet. A paying customer who hits a bug emails support. A new signup who hits the same bug closes the tab.
That means your conversion rate absorbs the damage silently, and the drop is small enough to be attributed to marketing, seasonality or anything else.
The sequence
| # | Event key | Max gap from previous | What a stall here means |
|---|---|---|---|
| 1 | signup.submitted | n/a (opens the flow) | Nothing yet |
| 2 | verification.email.sent | 60 seconds | Email provider failing silently |
| 3 | email.verified | 48 hours | Normal: many people are slow |
| 4 | workspace.provisioned | 2 minutes | Verified user with no account |
| 5 | welcome.sequence.started | 10 minutes | No onboarding guidance |
| 6 | first.action.completed | 7 days | Signed up, never activated |
Step 2 is the one to watch hardest. If your transactional email provider suspends your account, hits a rate limit, or silently drops to spam, every single signup stalls and your application reports no errors whatsoever.
Step 3 is long on purpose. People verify email the next morning, and a tight limit here would alert on ordinary human behaviour.
Step 4 is the technical failure that looks like user drop-off. A user who verified their email and was never provisioned sees a broken product, and your funnel records them as someone who lost interest.
Separating two very different stalls
The distinction that makes this flow useful is between a user not doing something and your system not doing something. They need different limits and different responses.
User-driven steps get long windows and feed lifecycle marketing rather than alerts. System-driven steps get short windows and page somebody. Mixing them produces either noise or blindness.
The signal that something broke platform-wide
One user stalled at step 4 is an individual problem worth fixing. Fifteen users stalled at step 4 within an hour is an incident, and the difference matters for how you respond.
Alert on both, with different severities. A single stall creates a task; a cluster at the same step pages, because a cluster means the step itself is broken rather than one record being unlucky.
Why analytics funnels do not replace this
A funnel chart tells you 8% of users drop between verification and activation. It does not tell you which users, it does not alert, and it usually updates daily rather than in minutes.
More importantly it cannot distinguish a user who lost interest from a user whose provisioning job failed. Both appear as the same drop, and the second is fixable while the first is not.
Per-instance tracking gives you names and timestamps, which means you can recover the specific people affected by an incident instead of writing off the cohort.
Recovering the affected users
The payoff is that after fixing a provisioning bug, you can list exactly who stalled during the window and re-run their provisioning, then email them personally. That converts an incident into a recovery rather than a permanent loss.
SensaCat opens an instance per signup and alerts on the ones that go overdue. Start free.