Is JitBit down?

1. Top 20 Helpdesk Interview Questions (with answers)

   Ongoing ● 6d 22h

   Started Jun 06, 2026, 08:21 PM UTC

   Timeline · 1 update

   • monitoring · Jun 06, 2026, 08:21 PM UTC

     Help desk interviews usually test two things at once: whether you understand the technical basics, and whether you can explain those basics to a person who may already be annoyed, confused, or late for a meeting. That combination matters. A support technician who can diagnose a network issue but makes the user feel stupid will struggle. So will a friendly person who guesses randomly at technical problems. The best candidates show both: methodical troubleshooting and calm, useful communication. Below are common help desk and desktop support interview questions, with sample answers you can adapt to your own experience. Technical Help Desk Interview Questions 1. Can you tell me about yourself? Keep the answer focused on the job. Mention your IT training, support experience, certifications, customer service background, and the kind of technical problems you have handled. Avoid turning it into a life story. A good answer gives the interviewer several useful follow-up paths. For example: "I have been building my support skills through Windows troubleshooting, networking fundamentals, and customer-facing work. I enjoy breaking problems down, documenting what I find, and helping users get back to work without making the process more stressful for them." 2. A user says their monitor is not working. What do you check first? Start with the simple physical checks before assuming a complicated failure. Confirm that the monitor has power, the brightness is not turned all the way down, the video cable is connected securely, and the computer itself is powered on. If the monitor has multiple inputs, make sure the correct input is selected. If those checks do not solve it, continue with another cable, another monitor, or another port. From there, you can investigate graphics drivers, docking stations, sleep state problems, or hardware failure. 3. What is Safe Mode used for? Safe Mode starts Windows with a limited set of drivers and services. It is useful when a normal startup fails, when a bad driver causes crashes, or when you need to remove unwanted software that loads during a standard boot. The exact steps depend on the Windows version, but the general idea is to restart into the recovery or advanced startup options and choose Safe Mode or Safe Mode with Networking. 4. What is an IP address? An IP address identifies a device on a network so other devices know where to send traffic. On a typical office network, a computer may receive its IP address automatically from DHCP, although servers, printers, and network equipment often use fixed addresses. On Windows, you can check the assigned address with ipconfig or ipconfig /all in Command Prompt. You can also find it in the network adapter settings. 5. What is a default gateway? A default gateway is the device a computer uses when it needs to reach something outside its local network. In many offices and homes, that gateway is a router or firewall. Without a working gateway, a computer may still talk to nearby devices but fail to reach the internet or other remote networks. 6. What is Active Directory? Active Directory is Microsoft's directory service for managing users, computers, groups, permissions, and policies in a Windows domain environment. In practical help desk work, you may use it to reset passwords, unlock accounts, check group membership, or confirm which computers belong to the domain. 7. What is a windows domain? A domain is a centrally managed group of users, computers, and resources. Instead of each PC having completely separate local accounts and permissions, a domain lets administrators manage access from one place, usually through Active Directory. For help desk work, this matters because a user's ability to sign in, access file shares, use printers, or launch certain applications may depend on their domain account and group memberships. 8. A printer is printing strange symbols or garbled pages. What might cause that? A common cause is the wrong printer driver or a corrupted print job. I would first clear the print queue, confirm the correct printer model and driver, and reinstall or update the driver if needed. I would also check whether other users are affected, because that helps determine whether the issue is local to one workstation or shared across the printer or print server. 9. What are common Ethernet cable categories? Common twisted-pair Ethernet cable categories include Cat5e, Cat6, and Cat6a. Cat5e is widely used for gigabit networking, Cat6 is also common for gigabit and shorter 10 GbE runs, and Cat6a is designed for 10 GbE over longer distances. In an interview, it is usually enough to show that you understand the categories affect supported speed, distance, and installation quality. 10. What is a blue screen? A blue screen, often called a BSOD, is a Windows stop error. It can be caused by failing hardware, bad drivers, memory problems, disk issues, overheating, or low-level software conflicts. A sensible troubleshooting path is to note the stop code, check recent changes, review Event Viewer, update or roll back drivers, run hardware diagnostics, test memory, and look for patterns such as crashes only after docking, printing, or launching a specific application. 11. What does DHCP do? DHCP stands for Dynamic Host Configuration Protocol. It automatically gives network settings to devices, including IP address, subnet mask, default gateway, and DNS servers. Without DHCP, users or administrators would have to configure those values manually on each machine. 12. What does DNS do? DNS translates names people can read into IP addresses computers can use. For example, when someone visits a website, DNS helps find the server behind that domain name. In support work, DNS problems can look like "the internet is down" even when the network connection itself is working. Useful checks include trying another site, using nslookup, checking the DNS server address, and flushing the local DNS cache when appropriate. 13. What is a VPN? A VPN creates an encrypted connection from a user's device to a private network. Remote employees often use VPNs to access internal applications, file shares, intranet sites, or administrative systems that are not exposed to the public internet. When troubleshooting VPN issues, check credentials, MFA prompts, internet connectivity, client version, certificate problems, and whether the user is on a restricted network. 14. What is the ping command used for? ping sends test packets to another host and reports whether replies come back. It is a quick way to check basic reachability and latency. It does not prove that a website, file share, or application is working, but it can help narrow down whether a device can reach another device at all. 15. What is Group Policy? Group Policy is a Windows feature used to apply settings across users and computers in a domain. Administrators can use it to configure password rules, mapped drives, desktop restrictions, security settings, software deployment, browser settings, and many other policies. For a help desk technician, Group Policy is often relevant when a user cannot access a feature that someone else can, or when settings keep changing back after a reboot or login. 16. What is a PST file? A PST file is an Outlook data file, commonly used to store email, calendar items, contacts, and archives locally. In support scenarios, PST files come up during Outlook migrations, archive recovery, mailbox troubleshooting, and storage cleanup. 17. How would you change folder permissions? First, confirm who should have access and whether the folder is local, on a file server, or controlled by a broader policy. On Windows, folder permissions are usually managed from the Security tab in the folder properties, where an administrator can add users or groups and assign permissions such as Read, Modify, or Full Control. In a company environment, it is usually better to grant access through security groups rather than adding individual users one by one. 18. What is the difference between a hub and a switch? A hub sends traffic out to every connected device, whether the traffic is meant for that device or not. A switch is smarter: it learns which devices are connected to which ports and forwards traffic only where it needs to go. That makes switches much more efficient and secure for modern networks. Hubs are mostly obsolete, but interviewers still ask the question because it tests basic networking knowledge. 19. How would you recover files from a virus-infected computer? Do not rush to copy files from an infected machine onto the network. First isolate the computer, document symptoms, and follow company security procedure. If recovery is approved, use a clean, trusted environment and scan the drive with updated security tools before moving any files. Depending on the incident, the correct answer may involve escalating to security, preserving evidence, or restoring from a known-good backup rather than manually extracting files. 20. Why should we hire you? Use this answer to connect your skills to the role. Mention technical fundamentals, reliability, communication, willingness to learn, and any experience that proves you can handle real users under real pressure. A strong answer is specific: "You should hire me because I can troubleshoot methodically, explain technical issues clearly, and stay patient when users are stressed. I also document my work, ask for help before wasting time, and keep learning so I can solve more problems independently." Customer Service Help Desk Interview Questions Technical answers matter, but help desk work is still service work. Interviewers want to know how you behave when the problem is unclear, the user is frustrated, or the ticket queue is already full. 1. What makes someone good at help desk work? A good help desk employee listens carefully, asks clear questions, and explains the next steps without drowning the user in jargon. They also know when to keep troubleshooting and when to escalate. Speed matters, but accuracy, documentation, and the user's experience matter too. 2. What do you do when you cannot solve an issue? I would gather the important details first: what changed, who is affected, what error appears, what has already been tried, and how urgent the issue is. If I still cannot resolve it, I would escalate with clean notes so the next person does not have to start from zero. 3. How do you handle an angry or frustrated user? Stay calm and avoid arguing. Let the user explain the problem, acknowledge the impact, and move the conversation toward the next useful action. A simple sentence like "I can see why that is frustrating; let's check the fastest things first" can lower the temperature without making unrealistic promises. 4. Tell me about a conflict you had and how you resolved it. Choose an example where you stayed professional and solved the actual issue. The best answers are not dramatic. A misunderstanding about priority, a handoff problem, or a disagreement about procedure can work well if you explain what you learned and how you prevented it from happening again. 5. How would you rate your troubleshooting ability? Be confident but realistic. If you are early in your career, a four out of five is often more believable than claiming perfection. Explain that you are strong at structured troubleshooting, documentation, and asking good questions, while still knowing when to escalate unfamiliar problems. 6. How do you keep your IT knowledge current? Mention specific habits: reading vendor documentation, practicing in a lab, following release notes, taking courses, studying for certifications, or learning from tickets after they are resolved. Interviewers like answers that show steady curiosity rather than vague "I read online" statements. 7. Why do you want to work in help desk? A good answer connects problem-solving with service. You might say that you enjoy figuring out technical issues, helping people get unstuck, and learning a wide range of systems. Help desk roles expose you to many parts of IT, which makes them a strong starting point for a support career. 8. How do you stay organized? Talk about your system. For example, you might prioritize tickets by urgency and impact, keep notes inside the ticket, use reminders for follow-ups, and close the loop with users before marking work complete. The point is to show that you do not rely on memory alone. 9. Is teamwork important in help desk? Yes. Support teams depend on clean handoffs, shared knowledge, and good escalation notes. No one knows every system, and many incidents require cooperation between help desk, infrastructure, security, vendors, and department managers. 10. Which ticketing systems have you used? If you have used a ticketing system before, name it and describe what you did with it: creating tickets, assigning priorities, documenting work, escalating issues, using canned responses, or building a small knowledge base. If you have not used one professionally, say so honestly, then explain that you understand the core workflow: capture the request, categorize it, prioritize it, document progress, communicate updates, and close the ticket when the user confirms the issue is resolved. Final Tips Before the Interview Practice explaining technical ideas in plain language. Prepare a few real examples from school, work, home labs, or previous customer service jobs. Do not pretend to know something you do not know. Explain how you would find out. When answering troubleshooting questions, start simple and move step by step. Show that you care about documentation, follow-up, and the user's experience. The strongest help desk candidates do not sound like they memorized a script. They sound like people who can stay calm, think clearly, and keep a user informed while working through the problem.

   Latest: Help desk interviews usually test two things at once: whether you understand the technical basics, and whether you can explain those basics to a person who may already be annoyed, …

2. How big should your IT helpdesk team be?

   Ongoing ● 20d 9h

   Started May 24, 2026, 09:00 AM UTC

   Timeline · 1 update

   • monitoring · May 24, 2026, 09:00 AM UTC

     How many IT people do you need for 100 employees? Or 500? Or 1,000? The honest answer is: it depends. That is not very satisfying, but it is usually true. A single-office company with managed laptops and mostly SaaS apps is a different job from a school district with thousands of student devices, projectors, cameras, phones, access points, and six buildings that all need someone on site when things break. Still, "it depends" should not mean "nobody knows". There are useful starting points, and there are also some real-world ratios that show how badly some teams are stretched. A reasonable starting point For a normal office environment, 1 IT/support person per 75-100 users is a decent planning range. This assumes you have basic standardization, a ticketing system people actually use, documented repeat work, and not too many physical locations. If the environment is more complex, the ratio should move down. More sites, more hardware types, more on-prem infrastructure, more compliance, more business applications, more special cases: all of these mean fewer users per IT person. Recommended IT helpdesk staffing ranges Horizontal bar chart showing recommended planning ranges for users or devices per IT support person by environment type. Recommended planning ranges Use these as planning ranges, not promises. Lower ratio means more support capacity. 0 50 100 150 200 250 Chaotic / BYOD / little standardization25-50 users Finance / compliance-heavy25-65 users Professional services / engineering50-75 users Standard office, good controls75-100 users Retail / warehouse / many locations75-125 users K-12 / education100-175 users Manufacturing100-200 devices There are two details worth calling out. First, manufacturing is shown in devices, not users, because the number of people on payroll may be a poor proxy for support load. Shared terminals, scanners, label printers, shop-floor PCs, and production systems all create work. Second, schools are shown with a more conservative recommendation than many schools actually get. Education IT often has a huge amount of hardware per user, and downtime tends to be very visible. If the projector, Wi-Fi, or login system is broken, a classroom full of people immediately knows. Real life is often worse Here is the sad part: real-world examples often show much higher ratios than the planning ranges above. These numbers are not recommendations. They are examples of what teams are actually carrying in some environments, based on our own data and publicly available sources. Observed real-world IT staffing ratios Horizontal bar chart showing observed real-world users or devices per IT support person. These are not recommended staffing levels. Observed real-world ratios, not recommendations These are examples of what teams were carrying. Some are clearly understaffed. 0 250 500 750 1000 1250 1500+ Finance, heavy app/infrastructure load35:1 Small company, broad IT roles38:1 Healthcare83:1 Cloud-heavy office120:1 Service desk only186:1 Multi-site in-house IT250:1 Manufacturing400 devices:1 Solo IT role500:1 K-12 school district586:1 K-12 / education700:1 Large school environment1300:1 The education numbers are the ones that stand out the most. They should not be read as "schools can support 700 users per IT person". A better reading is: many school IT departments are supporting far more than the usual office staffing model would suggest, often while also handling classroom hardware, cameras, phones, access control, wireless, curriculum systems, and state reporting. The same caveat applies to manufacturing and multi-site retail. If one support person is responsible for hundreds of devices spread across buildings or towns, the ticket count may not fully show the work. Travel time, spare equipment, vendor coordination, and production downtime all matter. Why the 1:100 rule breaks The 1:100 rule can work in a plain office with controlled devices, good identity management, and a small number of well-understood applications. It becomes less useful as soon as the environment stops being plain. A 100-person company with mostly cloud apps and managed laptops might be fine with one strong IT generalist. A 100-person company with warehouse operations, on-prem servers, compliance requirements, custom business applications, badge access, cameras, and five locations is a different workload even though the employee count is identical. This is why user count should be only the first number, not the final argument. A better staffing discussion includes the support surface area: How many endpoints are supported, and how many different types? How many physical locations need coverage? How much infrastructure does the team own? How many business applications require support? How much work is project work rather than tickets? How often is support blocked because only one person knows a system? There is also the classic solo IT problem. One person may technically support 300, 400, or 500 users for a while, especially if management only looks at payroll cost. But that person is usually also doing purchasing, vendor management, endpoint management, networking, security, onboarding, offboarding, and every escalation. Even if the tickets are getting closed, the risk is obvious: no backup, no depth, and no real vacation coverage. What to measure before asking for headcount If you want to make a staffing case, bring helpdesk data instead of just quoting a ratio. The ratio helps frame the conversation, but the operational numbers show whether the team is keeping up. Tickets per month. A 100-person company opening 400 tickets a month is not the same as one opening 40. Open ticket backlog. Backlog tells you whether the current staffing level works or whether tickets are aging in the queue. Time to first response. This shows whether users are getting acknowledgement quickly or waiting in silence. Time to resolution. Track this by category, especially onboarding, password resets, laptop swaps, access requests, VPN, printers, and Wi-Fi. SLA misses. If even low-priority tickets miss basic SLAs, the team is either under-resourced, poorly organized, or missing the right skills. First-contact resolution. If everything escalates, the first fix may be training, permissions, documentation, or triage rather than another hire. Device count and variety. 500 identical laptops is one kind of workload. 500 mixed laptops, scanners, shared warehouse PCs, cameras, phones, iPads, lab machines, and vendor boxes is another. Sites and travel. A 500-user single office and a 500-user company across 50 locations should not be staffed the same way. Infrastructure ownership. On-prem servers, firewalls, SANs, access control, internal apps, and compliance all consume time even when no user has submitted a ticket. This is why the ratio should be adjusted by complexity: Main drivers of IT support load Pie chart showing major drivers of helpdesk workload beyond user count. What actually drives support load User count matters, but it is only one part of the mess. Not just users Ticket volume and SLA expectations - 30% Device count and device variety - 25% Sites, travel, and local coverage - 20% Infrastructure and applications owned - 15% User skill, standards, and automation - 10% The percentages are a sizing model, not physics. Use them to start the argument in the right place. If you already use a helpdesk system, this is where the data should come from: ticket counts, queues, aging, categories, SLA misses, repeat work, and escalations. The staffing discussion gets much easier when it is based on the work entering the system and the work left unfinished. A simple staffing model Start with the ratio that matches your environment, then adjust it with the data above. Move toward 1:25-50 if the environment is chaotic, BYOD-heavy, under-documented, or full of exceptions. Move toward 1:50-75 if the team supports mixed infrastructure, multiple business applications, compliance, or a lot of hands-on support. Use 1:75-100 for a reasonably standardized office with good automation, good documentation, and a ticketing process people actually use. Treat anything above 1:150 as a warning sign unless the environment is unusually simple or a lot of work is outsourced. A useful headcount argument usually looks something like this: We have 500 users. We support 900 laptops/desktops, 80 phones, 120 cameras, 35 access points, 20 servers, and 8 sites. We close 1,600 tickets per month. We miss 22% of our low-priority SLAs. One person is primary for firewalls, switching, MDM, Microsoft 365, backups, imaging, and onboarding. Based on the environment, 1:100 is not the right planning ratio for us. That is much harder to dismiss than "we are busy". It also gives management choices: hire, outsource, reduce scope, improve tooling, standardize more aggressively, or accept slower service. At least the tradeoff is visible. The responsibility matrix is worth doing One of the simplest ways to expose staffing risk is a responsibility matrix. Open a spreadsheet. Put every technology area your team owns in column A. Then put every IT person across the top, including the manager. For each technology, mark one person as Primary and one as Secondary. The Primary owns the system: standards, upgrades, documentation, long-term decisions. The Secondary knows enough to support it, find the docs, and keep things moving when Primary is out. Everyone else should still know enough to triage before escalating. Here is a shortened example: Area John Erica Jim Mike Tom Windows Desktop Imaging Primary - Secondary - - Anti-Virus Primary Secondary - - - Patch Management (Windows) Primary - - - Secondary Remote Access VPN Primary Secondary - - - Internet Firewalls Primary Secondary - - - LAN Engineering Primary Secondary - - - Login Scripts & GPOs - - Primary - Secondary Active Directory - - Primary Secondary - DHCP - - Primary Secondary - Internal DNS - - Primary Secondary - If your real spreadsheet is not at least 100 rows deep, it is probably missing things. Windows imaging, MDM, antivirus, endpoint detection, backups, firewalls, switches, Wi-Fi, VPN, DHCP, DNS, GPOs, Microsoft 365, Google Workspace, SSO, payroll exports, badge access, camera systems, printers, onboarding, offboarding, vendor portals, compliance evidence, certificate renewals, monitoring, logging, DNS records nobody remembers creating. The list gets long quickly because IT owns a lot of small systems that only become visible when they break. This matrix helps in three ways: It shows whether one person is primary for too many important systems. It turns vague training needs into specific ones: Jennifer needs DHCP, Larry needs firewall basics, Darnell needs imaging. It makes business continuity risk visible. If one person leaving or going on vacation breaks six critical areas, that is a staffing and documentation problem. It also makes the headcount conversation less personal. Instead of saying "I am tired", you can say "we have 117 owned technology areas, 73 have no secondary owner, and our only firewall person is out next month". That is a much clearer operational risk. My take For a reasonably controlled office, start around 1:75 to 1:100. Move closer to 1:50 when the environment is physical, regulated, multi-site, heavily on-prem, or full of one-off systems. If the number goes above 1:150, look carefully at what is being ignored, outsourced, delayed, or carried by one person. The ratio is only a shorthand. The real question is whether the team can respond on time, resolve work without an unhealthy backlog, maintain the systems it owns, document enough to survive vacations and turnover, and still do project work without everything else falling behind. If the answer is no, the team is understaffed no matter what the spreadsheet ratio says.

   Latest: How many IT people do you need for 100 employees? Or 500? Or 1,000? The honest answer is: it depends. That is not very satisfying, but it is usually true. A single-office company w…

3. We let AI answer support tickets for a week. It one-shotted 70 out of 104.

   Ongoing ● 29d 18h

   Started May 15, 2026, 12:00 AM UTC

   Timeline · 1 update

   • monitoring · May 15, 2026, 12:00 AM UTC

     If you contacted our customer support recently, you probably talked to Lucie. She is great, but she was on vacation last week and I didn't want to deal with a lot of support tickets by myself. So I thought that maybe it was time to go YOLO-mode and see if our AI features were actually usable, or if we were lying to ourselves. On Friday, while my co-founder Alex was on a plane — he would've never approved this — I turned on this automation rule: Whenever a new ticket came in, AI generated and sent the first reply automatically. To be clear: this was not completely reckless. AI had already been generating draft replies for us on all new tickets for a while. But drafts are one thing. Sending AI replies directly to customers is another. I was a bit scared of this experiment and I honestly didn't know what would happen. What happened: out of 104 tickets we got that week, 70 were one-shotted by AI. By “one-shotted” I mean resolved instantly without human intervention. The customer got an AI reply, it answered the question, and the ticket did not need me or anyone else to step in. I still reviewed all the replies after they were already sent, but other than that it didn't require any effort from me. 70 tickets were resolved with one generated reply instantly. Roughly two thirds of our support load was gone. The tickets were different: technical and non-technical, easy and hard, billing, bug reports, feature requests. The rest — about 30 or so tickets — were handled with an easy follow-up from me, AI-generated more often than not. I was able to focus on the tickets that actually required me. This was all done with our current AI features. I wanted to use this article to show how the setup worked and do a kind of “State of Jitbit AI” thing. Small note: AI changes fast and Jitbit changes with it. We constantly add features, tweak stuff, etc. Most of this article should stay relevant, but some of it could become outdated quickly. Why it worked The truth is AI responses are only going to be as good as the context we provide. It's not entirely magic. The model needs information to compose useful responses. In Jitbit we get that context from several sources: Your Knowledge Base. AI can search it and retrieve relevant stuff. That's good, but not everyone uses KB, it's empty for new customers, and it could be an unmaintained mess like ours. External docs. You can give us a URL to your docs, marketing site, or anything publicly accessible via internet and we index that information for AI to use. Ticket history search. This is the newest addition and maybe the most valuable one. AI can now search your old tickets to see how similar issues were resolved before. External tools / MCPs. AI can call tools you connect to Jitbit. More on that below. We have a bunch of information in KB and our docs are pretty good. Those sources alone were probably enough to resolve a lot of tickets. But I wanted to go deeper. The billing tool I absolutely hate dealing with tickets about billing. “What's the status of my purchase order?” “Why did my subscription expire?” “I've sent a check with a pigeon last month. Did you get it?” My brain dies. Hate it. So I had an idea. We added the ability to connect external tools to the AI stack. This is going to get a tiny bit technical — bear with me. External tools are just HTTP endpoints that Jitbit AI can call in a given format to do something. So I added a tool called ask_billing. It was vibecoded in about 30 minutes. It's a thin HTTP wrapper around Claude Code. Basically, a sub-agent that can deal with billing issues. This tool had instructions to use our payment provider API and look up orders, accounts, subscriptions, etc. I also added the ability to generate quotes and change contact details. I didn't want it to be able to do dangerous stuff like issuing refunds, so it's mostly read-only information. In normal-person terms: Jitbit AI could ask a separate billing agent to look things up instead of hallucinating or making me do it. That worked wonders. It started handling all the billing BS for me. The engineer tool Another tool I added is called ask_jitbit_engineer. It works the same way: thin Claude Code wrapper, but this time with access to our GitHub repo. Our docs are never going to be perfect, but the code always has the most recent answers. The main model in Jitbit can now ask this sub-agent very specific technical questions and get detailed responses. So instead of guessing based only on docs, AI can ask: “Where is this setting stored?” “Who can change ticket statuses and which settings does it depend on?” “How does this API endpoint actually behave?” And then use the answer in the customer reply. Was it perfect? No. Some replies were a bit too “AI support agent”. Some were not how I would have phrased them. Some tickets still needed a follow-up. I would not let it issue refunds, delete accounts, cancel subscriptions, or do anything irreversible. But for first replies and boring-but-answerable tickets, it was already good enough. Actually, better than good enough. It removed most of the repetitive first-response work for a week. What this means for Jitbit customers The built-in AI features are available to Jitbit customers on all plans at no additional cost. That includes AI replies, KB search, external docs indexing, and ticket history search. The external-tool setup is more advanced, but the mechanism is there too. You can connect Jitbit AI to your own systems and let it look things up instead of guessing. In our case, the billing tool was hacked together in about 30 minutes, and it immediately made support less annoying. That setup removed most of the repetitive first-response work for us for a week, and it's only going to get better as we improve Jitbit and the models improve too. I know you're tired of hearing about AI everywhere. Sorry, me too. Just wanted to let you know where we currently stand.

   Latest: If you contacted our customer support recently, you probably talked to Lucie. She is great, but she was on vacation last week and I didn't want to deal with a lot of support ticket…

4. SaaS update: tightening email authentication for *.jitbit.com addresses

   Ongoing ● 29d 18h

   Started May 15, 2026, 12:00 AM UTC

   Timeline · 1 update

   • monitoring · May 15, 2026, 12:00 AM UTC

     TL;DR We are changing SPF and DMARC handling for *.jitbit.com email addresses to "hard fail" after a wave of spoofing attacks, reach out to support if you're affected. Background For years we kept SPF and DMARC rules for email addresses under *.jitbit.com more relaxed than a security person would like. Not because we thought email spoofing was charming, but because real customer setups are messy. The kind of messy where someone sends mail through their own SMTP server, or SendGrid, or some internal relay last touched in 2014, but still uses [email protected] as the From address because that is what their users recognize. And for a long time, bending a little made the product easier to use. Unfortunately, the internet saw this tiny bit of flexibility and did what the internet does best: turned it into a problem. Hackers and spammers started abusing our .jitbit.com domain family by sending fake emails that appeared to come from customer subdomains. Think addresses like [email protected] or other convincing-looking tenant domains. The emails did not come from Jitbit (we have toh-ons of protections from that), but to a mail server or a human skimming quickly, they looked more credible than random garbage from a disposable domain. And replies to these messages could end up in our ticketing system, generating nice autoreplies & email confirmations - all using our name as a cheap credibility costume. So we are changing it Starting this week, we are tightening SPF and DMARC policies for *.jitbit.com email addresses to hard fail/reject. Now if an email claims to be from a *.jitbit.com address, but it is not authenticated as allowed to send for that domain, receiving mail servers will reject it instead of shrugging and letting it through. This is the correct security posture. But it is also the kind of change that can break weird-but-working setups, which is why we avoided doing it until the abuse got serious enough that the tradeoff flipped. Who might be affected You might be affected if you send outgoing helpdesk email through your own SMTP server, SendGrid, or another third-party mail service while using a [email protected] From address. If your mail is already sent through Jitbit's normal outbound mail path, you should not need to do anything. If your custom setup suddenly starts bouncing, failing DMARC, or disappearing into the modern email-deliverability swamp, please contact us at [email protected]. We will help you figure out the least painful fix, add your server to our whitelist, or something like that.

   Latest: TL;DR We are changing SPF and DMARC handling for *.jitbit.com email addresses to "hard fail" after a wave of spoofing attacks, reach out to support if you're affected. Background F…

5. AI features now run on-premise

   Ongoing ● 53d 18h

   Started Apr 21, 2026, 12:00 AM UTC

   Timeline · 1 update

   • monitoring · Apr 21, 2026, 12:00 AM UTC

     Short version: every AI feature we ship on the hosted helpdesk now runs on the self-hosted edition too. It's a separately licensed Docker add-on, perpetual license, one-time payment. Customer data stays on your network. Requires Jitbit Helpdesk v11.22 or newer. Why this took a while Our AI stack isn't a thin wrapper around an LLM API. It's a Python service running a local vector database (Qdrant), embedding models, and a RAG pipeline tuned against support-desk content. That's what makes "similar KB articles" surface the right article, and what keeps reply drafts grounded in your own documentation instead of hallucinated. Running that stack on our own hosting is one thing. Packaging it so your IT team can stand it up on your own hardware without babysitting Python dependencies is another. We sat on it until we had something we'd be comfortable supporting. What you get Similar-article suggestions inside tickets - ranked by semantic similarity, not keyword overlap Semantic KB search for end-users - results ranked by meaning AI-generated reply drafts grounded in your KB, writing-style rules, and the ticket context External documentation indexing - crawl your own docs, wiki, or any internal site and use it as AI context alongside the KB Choice of embedding model - free local model that runs on CPU, or OpenAI embeddings with your own key Generative provider - OpenAI, Azure OpenAI, or AWS Bedrock, customer brings their own key Feature parity with SaaS. No caveats about "basic" ChatGPT integration. How it ships A Docker Compose stack you drop in next to your existing Helpdesk install. Runs on Windows or Linux, bare metal or VM, Intel/AMD or ARM. Upgrades are zero-downtime and preserve Docker volumes — indexed data and cached models carry over. Full setup and system requirements are in the manual. Privacy This is the reason we finally built this. With the bundled local embedding model, nothing about your tickets, KB articles, or indexed documentation leaves your network. No embeddings sent to OpenAI. No vectors stored in a third-party service. The vector DB is a container on a host you own. If you want a generative model for reply drafts, you bring your own API key. Azure OpenAI and AWS Bedrock keep everything inside your existing cloud tenancy, with a BAA if you need one. For regulated on-prem buyers — healthcare, defense, financial services, government — this was the #1 reason you told us you couldn't adopt our AI features. It's no longer a reason. Pricing Licensed separately from the core Helpdesk product. Perpetual license, one-time payment, 1 year of updates included - same model as the rest of the on-prem lineup. No subscription, no per-agent add-on, no per-request fees. See the pricing page for the current price, and the on-prem AI landing page for the full feature list and requirements. Setup instructions live at jitbit.com/docs/ai-on-premise.

   Latest: Short version: every AI feature we ship on the hosted helpdesk now runs on the self-hosted edition too. It's a separately licensed Docker add-on, perpetual license, one-time paymen…

+5 more ongoing incidents — sign up free to track them all.