Every mail integration claims to be real-time. Push delivers in seconds and fails by going quiet; polling is bounded by its interval and nothing else. What the numbers are, and the five questions worth asking any vendor.
Every email-to-ticket integration advertises itself as real-time. Almost none of them are, and the ones that are pay for it somewhere else. If you are choosing how to connect a support mailbox, the honest question is not "is it instant" but "what is the worst case, and what breaks it".
Here is what the numbers actually are, and where the failure modes hide.
There are only two designs
Every mail integration is push or poll. There is no third option, and the marketing word "real-time" is applied to both.
Push means the mail platform tells you. You register a subscription against a mailbox, the platform holds a callback URL, and when a message lands it calls you. Latency is seconds, and it does not depend on how often you ask.
Poll means you ask. You open a connection on a timer, list what is new, and fetch it. Latency is bounded by your interval and nothing else.
In Ticku, Microsoft Graph in app-only mode is the only push connection. Both IMAP modes — delegated sign-in with XOAUTH2, and a stored username and password — are polled. That is not a Ticku limitation; IMAP has an idle extension but no durable webhook, so a polled loop is what IMAP is.
The interval is the latency
This is the part worth internalising, because it is the whole answer for a polled mailbox: nothing else fetches your mail. If the cycle runs every two minutes, then two minutes is your worst-case time-to-ticket, and no amount of tuning elsewhere improves it.
Ticku's intake cycle runs every two minutes. That number is a deliberate trade rather than a default, and it is affordable for specific reasons: a cycle costs between 1.7 and 2.9 seconds, and opens one IMAP connection per polled mailbox — a second only when there is mail to flag as read.
Two minutes also means cycles can in principle overlap, so both ends of that have to be safe. A stuck socket is capped at sixty seconds, well inside the gap. And a message that gets fetched twice does not become two tickets: dedup runs on Message-ID, so a re-fetched message resolves to the ticket it already created. Concurrency safety is what lets the interval be short in the first place.
Push has an expiry date, and that is where it fails
The failure mode people expect from push is the callback not arriving. The failure mode you actually get is subscription expiry.
A Graph subscription is not permanent. It carries an expiry and has to be renewed before it lapses, and if it lapses the mailbox does not error — it simply goes quiet. Mail keeps arriving in Exchange, tickets stop being created, and nothing raises its hand. A push integration that has stopped looks exactly like a support queue that has gone quiet on a slow week.
Which makes renewal cadence the number that matters for push, not delivery latency. Ticku renews subscriptions inside the same two-minute cycle that polls the IMAP inboxes, so a subscription is checked roughly every two minutes.
It did not always work that way. Renewal used to be a separate daily job, which meant a push inbox could sit up to twenty-four hours before anything checked whether its subscription was still alive. The delivery latency was seconds and the recovery latency was a day. Folding renewal into the frequent cycle is the fix, and it is the sort of thing worth asking any vendor about directly: not "how fast is delivery" but "how often do you check that delivery is still working".
Microsoft 365 has already made one of these choices for you
If your mailbox is on Microsoft 365, stored-password IMAP is not on the menu. Microsoft retired basic authentication for IMAP and SMTP AUTH in Exchange Online, so a username and password will not open a connection regardless of what any tool's settings screen offers.
That leaves two real options for a Microsoft 365 mailbox, and the choice between them is about consent rather than speed:
| Graph, app-only | Sign in with Microsoft | |
|---|---|---|
| Delivery | Push — seconds | Polled — up to the interval |
| Who approves it | A tenant admin, once | The mailbox owner |
| What it can reach | Every mailbox in the directory | That one mailbox |
| Stored secret | None | A refresh token, encrypted at rest |
Directory-wide access is a real ask, and a security reviewer is right to push back on it. Delegated sign-in is the answer when they do: it costs you push delivery and buys a scope limited to one mailbox, with no Global Admin involved.
Stored-password IMAP remains genuinely useful — for Gmail app passwords, Zoho, and on-premises hosts. It is only Microsoft 365 that has closed that door.
What to ask, whoever you are buying from
Five questions, and the answers are more revealing than any latency claim:
- Is it push or poll? If they will not say, it is poll.
- What is the polling interval, and can it be changed? That number is your worst case.
- If it is push, how often is the subscription renewed — and what happens if renewal fails?
- What happens when the same message is fetched twice? If the answer is not a dedup key, it is duplicate tickets.
- How do I find out that intake has stopped? Silence is the default failure of every mail integration ever built, and a queue that has stopped looks identical to a quiet week.
None of these is a trick question. They are the four or five decisions that separate an integration that survives its first outage from one that quietly stops on a Friday and gets noticed on Monday.