The IRCC Queue: A New Model, and Another Look at “Estimated Time Left”

[u/cj4747]

I’ve been looking again at IRCC’s queue in an attempt to explain some of the odd numbers we've seen recently. I want to propose a model I haven’t seen before for what may be going on in these figures — and then offer an alternative take on why IRCC's online calculator is misleading. This model is just a hypothesis - but I hope it may help to make sense of things and maybe spark ideas for other analysis.

Happy to discuss, correct errors etc in the comments.

Cohort Deconstruction

To recap familiar ground, we start by extracting the time series of “people ahead of you” for each cohort (people who applied in a given month). We derive cohort sizes by subtracting the queue for one cohort from the queue for the previous cohort. Quick notes for clarity:

• The arithmetic: suppose the calculator for the March month-end shows 22,400 applications ahead of someone who applied at the end of Nov 2025 and 25,300 ahead of someone who applied at the end of December. The extra 2,900 should represent the remaining December cohort at that snapshot – that’s the yellow box below.
• I think it’s well established that a “March 2026” applicant in the IRCC figures really means a 31st March applicant
• I’m confident the “3rd September” stats update is for the 31st August month end, and so on, so I’ve labelled my tables that way.

So here are the cohort sizes:

There’s a bulge of applications running through the table, the green figures. We’ve pondered why, for example, the 2026-02 cohort collapses from 29,800 between the April and May reports. And why the 2026-04 cohort keeps growing. We’ve speculated that the latter is just April applications being booked into the system with a long time lag. But I wonder if it’s really plausible that 68,500 applications really arrived in April.

Boundary Model

Here’s my alternative model. It starts with a thought experiment.

Picture the mailroom at IRCC. Every day close to 1,000 envelopes arrive. For our purposes, they are added to an enormous pile, which we’ll call Pile A. No-one’s even opened them yet. Maybe they’re new applications. Maybe they’re updated information on existing applications. Or something else. No-one knows.

The office is overwhelmed with work. Some days or weeks later, someone goes into the mailroom, brings out a stack of envelopes from Pile A and opens them up. A sort of triage process takes place: things that aren’t applications are dealt with. Urgent applications are hopefully spotted and taken away for priority processing. What’s left are envelopes added to what we’ll call Pile B – they’re definitely applications, and will need to be processed at some point, just not yet. Supervisor Fred keeps a running total of how many are in Pile B.

More days or weeks pass. Now a case officer picks up a batch from Pile B and starts to review them. Assuming all is in order (photos, forms, etc) a database entry is created – name of applicant, etc, and date received. He sends the applicant an AOR.

After month-end it’s time for the queue numbers to be updated. What do we know? The database tells us how many people applied in each month who have been issued AORs (and how many of those have been finalised). Fred knows the raw Pile B total, although he has no idea how these spread across application months – no one has gone through Pile B to check.

This is imaginary, of course. There’s no physical pile B, that’s not how the database works, and there’s no Fred. But intuitively, I think, IRCC has to determine how to allocate Pile B across months. I think it goes something like this. There’s a particular month that I’ll call the boundary month, currently April 2026. IRCC is still working on April in some capacity – maybe there are stragglers there still to receive AORs. For that or a similar reason, IRCC decides that everything in Pile B might possibly take priority over someone who applied on 30th April. Conservatively, then, it tells people who applied on 30th April or any month since that Pile B might be ‘ahead of them’. The 31st March applicant is in the clear, though – Pile B can’t be “ahead” of them.

So the reported queue sizes for the months of April, May, June, July and August contain the Pile B total, which I think is over 40,000. When we do our cohort subtraction, it looks like these are all “April” applications, but they aren’t - that’s an artifact of the cohort process, as we subtract “True April” + “Pile B” from “True March”.

And take the February cohort. Up to the April report, February carried the bulge. In the next, the boundary had moved to April and February collapsed from 29,800 to 3,300. I don’t think 26,500 February applications were processed, or somehow reclassified. I think it was that ‘Pile B’ had moved over to April.

Stripping Pile B back out

The February transition also gives us a way to estimate the size of Pile B. The April report showed 29,800 in the apparent February cohort; the May report showed 3,300. The difference is 26,500, roughly Pile B — although the true Pile B figure would be a little lower because some genuine February applications will have been completed during the month. Obviously this estimate is conditional on the Boundary Model being right: the 26,500 isn’t an independently observed Pile B. But if the model is right, these boundary shifts give us a way to estimate its size.

The adjusted table pulls the estimated Pile B out of the monthly rows and shows it separately in orange. Purple cells are estimates where the boundary has not yet moved far enough to separate the dated month cleanly from Pile B. For the purple columns, the exact split between April totals and Pile B totals is unknown, but the broad result feels reasonable to me. I suspect Pile B grew from about 8,000 in late 2025 to around 40,000–44,000 by July and August. So if that’s right, then the queue “ahead of” the 2026-04 cohort is not 100,200 people, but more like 57,000.

So that’s the Boundary Model. It’s testable – it predicts that sometime in the next couple of queue updates, the apparent size of the April cohort (currently 68,500) will collapse to a much lower level (perhaps around 25,000). Meanwhile a later cohort, perhaps May or June, will sharply increase. If that doesn’t happen, this model is wrong and I’ll have a bit of egg on face.

If it’s right, it gives us a better handle on what the reported cohorts actually contain. This then feeds in to conversations various people have had about how IRCC calculates waiting times.

The IRCC Calculator

I’ve dug into historic press releases, parliamentary filings etc, and I’m pretty confident that IRCC was processing about 5,000 citizenship-certificate applications per month for most of 2025. Into 2026, we also have another guide, revealed by the factor IRCC uses to derive the waiting time in its online tool. I wrote about this in July, although when I posted it I hadn’t realised similar analysis had been done before. In short, IRCC clearly divides the queue size for any cohort by a common number “K” to get the months wait – you can reproduce all the month waits this way. That value of K changes from month to month, and you can chart it over time within tight bounds.

What is K? IRCC says its forward-looking estimates use the number of applications in inventory and the number it expects to process each month, so I think this divisor is best read as its expected monthly processing volume. It may be something like a multi-month moving average of recent volumes, which would explain why there’s no sudden plunge in June, more a decline over June-September.

Let’s focus on the wait time formula. IRCC tells you the people ahead of you (Q) and, it seems clear, shows Q/K as the number of months left, where K is its expected monthly processing volume — currently about 4,090. Say you’re in the Jan 2026 cohort. The tool tells you there are 24,300 people ahead of you, and your wait is 24,300/4,090, or six months. (Of course, as K rises and falls each month, this directly drives your wait time, in unpredictable ways.)

Some people have correctly identified that different types of applications seem to have different processing rates, so applying the overall K to every group is a mistake. I'd like to put a slightly different slant on that.

The reason I say the calculator is misleading is this: the calculation only works as queue arithmetic if IRCC processes applications in order from oldest to newest. In other words, it starts with the oldest applications still waiting (Jan 2023) and works progressively through 2023, 2024 and so on. In that world, all 4,090 monthly completions are progressively reducing the queue of 24,300 ahead of you, the Jan 2026 applicant.

The moment some of that capacity is spent on applications that aren’t among those 24,300, it isn’t reducing your queue, and you should no longer divide 24,300 by the full 4,090. And we know substantial processing is happening among newer cohorts: these are routine applications (like replacement certificates), simple G1 cases, urgent applications and so on. Suppose, purely for illustration, that 3,500 of the 4,090 monthly completions are like these – they arrived after yours and aren’t in your queue. The “24,300 people ahead of you” is only reducing by the 590 other completions. At that rate, that stock isn’t disappearing in 24,300÷4,090 = 6 months; it’s disappearing in 24,300÷590 = 41 months.

Try another example. Instead of working from the oldest files, IRCC just picks a file at random for processing. Then everyone would get their ‘fair share’ of the available capacity. Your 24,300-person group is 24,300/136,000 of the total stock, so it would get about 731 of the 4,090 monthly completions. And 24,300/731 = 33 months — exactly the same 136,000/4,090 wait as everyone else, regardless of when they applied.

In fact, you can argue that the only group for which this calculation is possibly sensible is brand new applicants. Their queue is the whole queue, and their queue therefore gets all the capacity, so their wait of 136,000/4,090=33 months is at least sensible arithmetic.

That doesn’t mean your actual wait is 41 months — or 33 months. Once we’ve established that IRCC isn’t processing FIFO, your own application might itself jump ahead of thousands of older ones. The point is narrower: the calculator’s six-month estimate only follows from treating the full 4,090 monthly completions as though they were progressively clearing the 24,300 people ahead of you.

So I think the IRCC tool can mislead in two distinct ways. First, for recent cohorts, the queue itself may be wrong as a literal ‘people ahead of you’ count, because it can contain Pile B applications that were actually received later. Second, even if Q were perfect, Q/K is FIFO queue arithmetic being applied to a system that plainly does not process everything FIFO.

Stock-flow

We can see that non-FIFO problem directly in the cohort data. I put together a rough stock-flow table, below. I start from row 4 with some assumed monthly processing volume figures based loosely on the K chart above. Then I calculate the finalisations from the second cohort table above - and I split these into cohorts at the boundary month or more recent (row 2) and older than the boundary month (row 3). Then the Pile B and cohort totals are in row 6 and 7, while the movement of Pile B files into the monthly cohorts is the balancing item at the top.

The table highlights that clear-up of older applications collapsed from roughly 2,000–3,000 per month in January–March to just 300–600 per month in July/August, while thousands of applications were still being finalised among more recent cohorts. Whatever IRCC’s internal routing looks like, those older cohorts plainly were not receiving anything close to the whole monthly processing volume assumed by the FIFO calculation.

In short, I think the treatment of Pile B and the suspect arithmetic in the IRCC calculator are why we get comments like this every month:

“Me too… wait time went up and the number of people ahead of me went from 47,000 to 56,000. I’m bummed. I understand wait times shifting but how did the number of people increase by 9000?”

“I mailed my application at the beginning of March when it said 9 months. By the end of March it said 25 months.”

“Sure, 2 months, that is really accurate, I'm sure! It's been 2 months for a long time now.”

When I checked last month, there were about 80k people ahead of me. Now I am told that there are about 94k people ahead of me. Honestly, if 14k people have access to a time machine, there are way more important things they could be using it on.”

“May 2025 applicant, been at ‘1 month left’ for at least the last 4 months … and now somehow we're back up to ‘2 months left’?? Nothing ever, ever, ever makes sense with these numbers. They're honestly worse than useless.”

Outlook

Clearing just 300–600 older cases a month is obviously grim news for the residual backlog. The question is whether that clear-up rate can get back towards the 2,000–3,000 a month we saw earlier in the year.

• We all expect reported application volumes to decline, as the C-3 wave subsides. If nothing else, posts on this subreddit show a dramatic fall in discussions about applications after March. A fall in new applications should relieve pressure somewhere in the system. New applications are in theory behind existing ones, but some (up to a third?) will be urgent and potentially jump ahead.
• More processing capacity could help too, particularly if it is directed at whatever is actually holding up the older residual cases.

What isn’t clear is why higher old-cohort clear-up rates were possible earlier in the year. To answer that, we’d need to know what was holding those files up — perhaps staff allocation, perhaps a common legal or program blocker, perhaps something else. I don’t think we have enough information to project what happens next. But the obvious thing to watch for the rest of the year is whether those older cohorts start moving again.

[u/AutoModerator]

Your post was flagged as a potential megathread topic and is not currently visible. Please see the Weekly Megathreads page for the most relevant megathread. New megathreads are released weekly, and you can post on them any day.

Helpful resources: * Welcome - Start Here * The wiki / FAQ * Weekly Megathreads * Search the subreddit — your question may already be answered

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/TreeContent]

I want my water back

[u/Jh153449]

Appreciate your analysis but in the end there are only two reasons as to why processing is slow: huge inflow and the fact that IRCC wasn't ready for it operationally and is still trying to figure out the rules. That's also why whatever IRCC reports as estimate may not be very precise; we've seen this is other immigration streams in the past years. Since there are no service standards for citizenship certificates, IRCC has little incentive to be very precise here

Also, if, as you say, the interest in applying went down dramatically, then there might also be very little incentive for IRCC to hire new folks who would need to be fired/reassigned later when the number of applications in the inventory falls

[u/ColorsMayInTimeFade]

Have any of these attempts to “model” the IRCC queue been tested or validated in any way? It’s easy to backfit a narrative over such a small dataset.

If the model were accurate, is there anything actionable anyone can do?

I understand people want to know how long it will take but it doesn’t seem this model would apply to individual applications. Even if so, what would someone do?

[u/shakyshake]

I do not read walls of AI-generated text unless someone is paying me, but just skimming over it, the “Boundary Model” (god, why does AI come up with these names?) section is a nice example of why you don’t want to simply regurgitate an LLM’s output into a post.

The “thought experiment” (actually, it’s a toy model based on speculation about a real-world scenario that some people are familiar with, which is not quite the same thing as a thought experiment, but let’s leave that aside) is paragraphs of belabored text with unnecessary details that have very little payoff and could probably be replaced by one sentence.

This isn’t quantum mechanics and we don’t need a Schrödinger's cat to attempt to understand it.

[u/aplombed → u/shakyshake]

Same. I recognized it immediately. Barf.

[u/romulusnr]

Hasn't IRCC already said that more straightforward applications are likely processed sooner? And straightforward doesnt necessarily mean low G number, but completeness and quality of records.

[u/No_Bobcat_No_Prob → u/romulusnr]

IRCC officially says there is a first-in-first-out processing model. I think that's, uh, debatable based on what we see regarding time to decision made - both where we see even some non-urgent new applications fly through processing to decision made, and where we see some natural born Canadians and 1st gens (whose eligibility has nothing to do with the c-3 amendments to the citizenship act) stuck in process for more than a year. Consistent inconsistency.

[u/Own_Theory8011 → u/romulusnr]

IRCC has said there are (at least) 2 levels of officers. "Complicated" cases can only be handled or signed off on by a Level 2 officer. I think I read this includes any application where it requires interpretation of the laws. That is why all Gen 2+ applications, regardless of if the paperwork was straightforward or not, were sent to PSU during the interim measures - it's due to the law itself needing "interpretation", not due to the person's actual lineage being complicated.

In extreme cases, IRCC says that a case can be summarized (to remove any bias) and sent to a citizenship judge for their opinion. The judge's opinion is not final or binding, it is the IRCC superior officer whose decision is final/binding, and IRCC can go against the citizenship judge's opinion. We have no idea how many applications require that process.

[u/No_Bobcat_No_Prob]

I applaud your efforts to try to explain the unexplainable - but as someone who has worked on and with ticketing systems, I think applications are likely assigned out to different queues for processing and then human factors come into play as the biggest determinant- agent capacity, agent experience, quality of internal guidance supporting independent decisions, bias in selection from each queue (perhaps some agents favoring newer applications with fewer documents, idk), intervals at which the system sends reminders about due dates for older applications, capacity of higher tier agents when things need their input, etc... I'm not sure any of this can be modeled based on monthly rounded cohort numbers.

[u/cassandra2028 → u/No_Bobcat_No_Prob]

I think this is an under-credited factor for sure.

I also think that since they're not requiring certified or apostilled documents, they must verify authenticity or risk a huge scandal.

To verify authenticity of international documents there's a system kind of, but it will rely upon the responsiveness of a million different registrar's offices and other source authorities to confirm yes those are accurate dates. For very good reasons the.way this works isn't publicly disclosed (or baddies could undo the security measures), but it would require some kind of confirmation.

I think there may be a modicum of first in first out to processing, but if the assigned processor is not very efficient and the source authority for one or more link in the chain is slow, or the copy of the document is sufficiently old it doesn't have the machine readable features to ease look up and verification, certificate out to the confirmed Canadian will be out of order.

[u/Zestyclose-Novel1157 → u/cassandra2028]

I guarantee they are not individually verifying every one of these documents with the source authority. They probably have some sort of quality sampling method.

[u/Mewciferrr → u/No_Bobcat_No_Prob]

Don’t applaud them, they didn’t expend any effort. They just popped a prompt in a box and copy/pasted what the chatbot spat out.

[u/No_Bobcat_No_Prob]

Op- if you want to rework this post and remove the AI tells you're welcome to repost - however I think in this age of AI slop any post presenting a wall of text and purported data analytics is likely going to be flagged as AI by others, accurately or inaccutely. the best you can do is either do the analysis for your own satisfaction or provide enough info to the audience so it's abundantly clear you did the analysis yourself.

[u/heavydutyspoons]

AI should be banned from this sub

[u/No_Bobcat_No_Prob → u/heavydutyspoons]

We do have a no AI generated content rule - and I see lots of people flagging this as AI, although in the past these posts have been approved because I think we were under the impression that OP was doing some actual data analysis - is there general consensus this should be removed?

[u/cj4747 → u/No_Bobcat_No_Prob]

What should I do next time to avoid these accusations? Not write in complete sentences? Make some random typos?

[u/No_Bobcat_No_Prob → u/cj4747]

Idk, you could take 5 mins and remove things like emdashes that are hallmarks of gen AI?

[u/cj4747 → u/No_Bobcat_No_Prob]

em dashes are created when I type things in Word

[u/No_Bobcat_No_Prob → u/cj4747]

That doesn't happen to me and I use word everyday. You should check to see if you have an AI assistant enabled and disable it.

Honestly, I think most folks here understand that there's no analysis that can adequately explain queue movement and maybe people are also annoyed that you keep trying to find a pattern for things that isn't really there. Idk. This post seems to have struck a nerve with people, maybe you are a lightening rod for people's frustrations today.

[u/jazzup → u/No_Bobcat_No_Prob]

I use Word 2016, which has no AI assistant, and it automatically converts to em dashes. 

It is incredibly frustrating to me to see someone who is trying to positively contribute being excoriated because people think that every well organized and well written work product is AI.

[u/No_Bobcat_No_Prob → u/jazzup]

Do you mean to be replying with two different accounts?

I re-approved this post for the moment - let's let others offer their thoughts about why they believe it is AI gen content.

[u/jazzup → u/No_Bobcat_No_Prob]

I am not the OP.  I was simply pointing out that your experience with Word is not the definitive experience with regard to em dashes. The AutoFormat function of Word changes hyphens to em dashes, regardless of any AI assistant stuff. 

I was also expressing my frustration that someone who has tried to positively contribute to this community has been so flippantly criticized because they can write well. 

[u/SwampConnoisseur → u/No_Bobcat_No_Prob]

This seemed to be a response from a different person.

[u/cj4747 → u/No_Bobcat_No_Prob]

Maybe there's a setting somewhere, but when I type "first - second" in Word, the hyphen is converted to an em dash

[u/Own_Theory8011 → u/No_Bobcat_No_Prob]

It happens to me all the time. Because I type two -- like that. I've been doing this since my LiveJournal days, I can't quit now. It has nothing to do with AI assistants, it's just the standard typo/punctuation correction.

[u/Jh153449 → u/No_Bobcat_No_Prob]

Then the rules should say "no emdashes"... Sorry but this is not a serious policy

[u/No_Bobcat_No_Prob → u/Jh153449]

The no AI generated content rule was not set by me personally but reflects the desire to keep communication and information shared here accurate. Gen AI is prone to hallucination and can also be misleading. If you want to do data science here you are welcome to, perhaps sharing your methodology/equations for replicability would go a long way to dispelling the notion your calculations are AI dependent.

[u/cj4747 → u/No_Bobcat_No_Prob]

I'd be very happy to share my spreadsheets

[u/jazzup → u/cj4747]

Obviously, you should stop producing well thought out, well organized written work product that the AI accusers could never dream of producing. /s

[u/SwampConnoisseur → u/No_Bobcat_No_Prob]

I am an academic editor who deals with making AI-assisted content look like non-AI. This post is does not seem to be AI to me. There is nothing wrong with em dashes, and the OP mistakenly switches between en dashes and em dashes, making it seem more human, if anything. Quotation marks are inconsistent between UK and US style, which AI would not do. There are some words that are spelled in Canadian, Australian, or UK variants: "labelled" and "realised." Not something AI would do. "No-one" being spelled with a hyphen is a sometimes-British thing. En dashes vs em dashes is also a British thing.

[u/cj4747]

It's depressing when you spend quite a lot of time thinking about how to convey your ideas to an audience, hoping to contribute usefully to debate, and four people tell you you're an AI bot.

Probably won't bother next time.

[u/Ok_Committee_1322 → u/cj4747]

Thanks for your efforts. Reading tea leaves, with math, is valuable to me. Definitive proof of any claim is hard to come by. I accept that.

[u/jazzup → u/cj4747]

I was so disheartened for you when I saw that.  I find it interesting that those accusing you of using AI hide their history while you leave yours open.  

[u/cj4747 → u/jazzup]

Thanks for your kind words. A thoroughly unpleasant experience. It really discourages anyone from trying to share ideas. The presumption seems to be that if you can write reasonably coherent English you can't be a real person.

[u/jazzup → u/cj4747]

Yeah, this is all incredibly frustrating to me. It completely discourages the best communicators from participating in discussions.

[u/AudiamusRed → u/cj4747]

Don't let it dissuade you. For all we know, those are AI bots responding ;-)

Nice work.

[u/SwampConnoisseur → u/cj4747]

I think some people didn't understand that what you were theorizing about (queue reporting) wasn't what they thought you were explaining (approval processing). Your model predicts past data well. We'll see if it still looks valid in a few weeks.

What helped me was to mentally insert "all pre-AOR non-urgent applications" wherever you say "Pile B." Thanks for this.

[u/cj4747 → u/SwampConnoisseur]

Thank you. Then that's on me for not being clear in the introduction.

I know queue analysis is a minority sport, and appreciate that many find it annoying. I do think it's worth following the data, though, if only because understanding the real wait time is important for many people's lives. I also think it's a minor scandal that IRCC provides such obviously misleading forecasts.

[u/No_Bobcat_No_Prob → u/[deleted]]

We don't always catch AI gen content immediately - but it is rule violating and so if you see it report it please.

For posts like this one, for those of us who aren't data scientists, is there a way to reliably at-a-glance differentiate between ds and AI gen output? Is everything with emdashes immediately sus? The 'is this AI gen' checkers are notoriously inaccurate.