Full Width [alt+shift+f] Shortcuts [alt+shift+k]
Sign Up [alt+shift+s] Log In [alt+shift+l]
1

Security is speeding up

from Founder's blog [alt+shift+b] in programming

Binance lost $6.3 billion, a backdoored Claude Code extension went out to developers, and Polymarket was drained through someone else's monitoring script. That was just the last 48 hours. Insane. Here's the full list: Binance lost $6.3 billion. It's the largest crypto theft on record, about four times the size of the Bybit hack from last year. Most of it left in about 20 minutes. The Claude Code extension in Cursor's marketplace was backdoored. Someone published a tampered build under the official extension ID. It added an attacker's SSH key to the machine and set up persistence. It was live for about 11 hours and reached up to 5,000 developers. These are developers, so their laptops have production credentials on them. Polymarket got drained through somebody else's script. Attackers compromised DebugBear, a website performance monitoring service. Its monitoring snippet started serving malicious JavaScript that used logged-in users' sessions to move funds. Over $2 million was taken. DebugBear has asked all of its customers to remove the snippet while it investigates. Hetzner warned customers about a UEFI firmware flaw (CVSS 9.5, 16 years old) in the network boot code that runs before the operating system, and before Secure Boot can do anything about it. It affects their dedicated servers and UEFI cloud VMs. A maximum-severity GitLab flaw is being exploited in the wild, according to CISA. Federal agencies got a few days to fix it. Meanwhile, in the Linux kernel, a TCP bug was quietly re-scored from 5.9 to 9.8, which means unauthenticated remote code execution. As of Thursday, Ubuntu and RHEL still hadn't shipped patched kernels. There's also a 9.3 bug that lets a guest VM read host memory, and a local root bug that CISA says attackers are actively exploiting. The week before that, two critical PHP flaws dubbed "PHP2Shell" allowed unauthenticated remote code execution on basically any server running PHP 5.4 or newer. Governments didn't wait to find out whether they'd...
2nd Aug 2026

Stay updated

Get a weekly newsletter with the top 5 articles worth reading every week.

More from Founder's blog

Setting up a helpdesk team

Here's a situation we hear about from customers all the time. Someone gets hired as an IT support manager. They inherit two techs, a shared inbox (or a ticketing system nobody likes), and a mandate that sounds something like "build us a proper tiered support team." They have six months to show it's working. It's tempting to start shopping for software. But first you need to find out why everyone hates the current setup. A new ticketing system won't help much if the real problem is that nobody knows who's supposed to approve a laptop. Week one: listen more than you change The worst thing a new manager can do is walk in with a 40-slide transformation plan. Nobody has asked for it yet, and you don't know enough to write it. Instead, talk to as many people as you can, and not only in IT. Department heads, the finance team, sales, and especially the executive assistants. Assistants see every IT failure that annoys their boss, and they will tell you exactly what's broken. Ask what people like about how IT works today and what drives them crazy. You'll get a clear priority list surprisingly fast. Then sit down with your own techs. Ask what wastes their time, what they keep fixing over and over, what they'd change if they could. Pick something you can fix for them. Maybe they're chasing the same approval every week, or sharing one spare laptop between three offices. Sort that out before giving them another process to follow. A few more things to do early: Read the old tickets. If there's any history at all (even an email folder) go through a few months of it with the team. Look for repeat issues, common categories and the stuff that takes forever. This is your first real data. Get the brief from your boss in writing. What does "success" look like in six months? What's the budget? What level of maturity are they actually expecting? "A tiered support team" means something very different at 80 employees and at 2,000. Don't make drastic changes without backing. Changing how people ask for help affects the whole company. If leadership hasn't agreed to it, the first person who complains loudly enough will undo it. Record your starting point Before you change anything, save a few numbers. You'll want them when your boss asks what the last six months achieved: how many requests come in per week, through which channels, how long they take to get a first response, how long until they're resolved, and how many get reopened. The numbers will be rough. That's fine. Six months from now, when someone asks whether the new helpdesk made any difference, you want to answer with "first response went from two days to three hours" rather than "it feels better." The metrics that matter for a helpdesk are well known, so you don't need to invent your own. Agree on what the team supports A ticket can sit untouched because everyone assumes another team owns it. Work out where your team's responsibility starts and ends, including the awkward bits: What do we support, what don't we support, and if we don't, who does? When do we support it? Business hours only? Weekends? Is there an on-call rotation, and who pays for it? What's the difference between an incident (something is broken) and a request (I need something new)? They should be handled differently. Who approves things like software purchases, new accounts or access to sensitive systems? Who orders replacement hardware? Is there an asset inventory, and is it up to date? Is anything monitored, or do we find out about outages when users call? Who owns endpoint security, password management and change management? Write down the gaps too, and take them to whoever can make the decision. "We'll work out who's on call when something breaks" is a miserable arrangement for the person whose phone rings. Pick a ticketing tool. Don't build one You need a ticketing system, but you don't need the perfect one. Almost any modern helpdesk will handle what a team of three needs: tickets, email intake, a portal, a knowledge base, basic automation and reports. Pick something within budget that your team can set up in days, not months, and start using it. Resist the temptation to build something custom or to spend a quarter on a giant ITSM rollout. A team of two doesn't need it, and the time you spend configuring is time you're not fixing anything. (Obviously we'd suggest Jitbit Helpdesk, but the advice holds for any tool.) When you set up the portal, keep this in mind: make it simple for the people asking for help, not for the people answering. Your users don't know how IT works. If someone can't log in, they have no idea whether it's the VPN, their password, an expired license or a permission problem. Asking them to pick from 30 categories and route their own ticket to the "Identity & Access" queue guarantees misrouted tickets and annoyed users. Plenty of helpdesks are designed by helpdesk staff for their own convenience, and to the end user they feel almost hostile. Start with one big button: "I need IT help." Let your tier 1 tech read the ticket and decide where it goes. Once you see which requests come in again and again, add a few specific forms for them (new starter, access request, hardware order) and grow it into a proper category structure from real data rather than guesswork. One front door, and stick to it Once the system is live, every request goes through it. Not a DM to your favourite tech, not a hallway conversation, not a "quick question" in the team chat. Otherwise, a tech can spend all afternoon helping people and look idle in your reports. And when they're off sick, nobody knows what they were working on. This will be unpopular for a few weeks, so be consistent but not rude about it. When someone pings a tech directly, the tech logs the ticket on their behalf and replies with the ticket number. After a while people figure out that filing a ticket is faster. It helps a lot if the tool meets people where they already are, for example by letting them open tickets from Microsoft Teams or by email. The same goes for ticket quality. You're allowed to teach users how to ask for help. A ticket that says "the report doesn't work" should get a polite reply asking which report, what parameters, and what the error said. Better still, put those questions on the form with a ticket template. Templates also make patterns much easier to spot, because the same fields get filled in every time. Documentation: make it easy, not perfect If writing up a five-minute fix takes twenty minutes, the docs will always be out of date. Keep the routine notes quick to write. An informal internal knowledge base, owned by the techs. Every time someone solves something non-obvious, they write a quick entry: what the symptoms were, what the actual cause turned out to be, and how they fixed it. Three paragraphs, no formatting rules. If someone hits the same issue again, they add a short note ("seen again on March 4, this time it was the dock firmware"). Let everyone edit everything, keep backups, and stay out of the way. If every troubleshooting note needs your approval, you've given yourself another queue to clear and your techs another reason to put it off. SOPs for the processes that matter. Onboarding a new employee, offboarding someone, handling a lost laptop, escalating a security incident. Write these together with your techs, not for them. You'll get pushback, and the trick is to sit with them and draft the complex ones as a pair. Ask about the steps they usually leave out because "everyone knows that bit." Those are often the ones a new hire gets stuck on. AI can help turn rough notes into a procedure, but the tech still needs to check it before anyone follows it. Keep the docs near the tickets. Documentation spread across file shares, wikis and someone's OneNote is documentation nobody finds. If your helpdesk has a built-in knowledge base, use it, and link articles from the relevant categories and canned responses. A new tech should be able to find the fix without having to know who wrote it. Ticket history also helps when someone says "IT never told us." It's useful to be able to pull up the actual conversation instead of arguing from memory. ITIL: borrow, don't adopt You'll hear a lot of advice to get certified in ITIL and build everything around it. The concepts are valuable: the incident vs request split, problem management (fixing the root cause, not just the symptom), change management, a service catalog. Learn them. (We wrote a short explainer on ITIL vs ITSM if you need a refresher.) But for a team of three supporting a mid-sized company, a full ITIL implementation is mostly paperwork. Take the parts that solve problems you actually have and skip the rest. You can always add more formality as the team grows. Removing it later is much harder. Automate the repetitive stuff Once tickets are flowing through one system, you'll see exactly where the time goes. A few areas are almost always worth automating early: Joiners, movers and leavers. If your HR system talks to your identity provider, most of the employee lifecycle can run automatically. Account creation, group membership, license assignment and, more importantly, account removal when someone leaves. SaaS provisioning. If your apps support SSO and SCIM, user provisioning and deprovisioning can happen without a ticket at all. Software installs. Most MDM tools let you publish a self-service catalog. Approved software shouldn't need a tech. Password resets. Self-service password reset removes a whole category of tickets overnight. Distribution lists and shared mailboxes. A few simple scripts handle most of these. Triage inside the helpdesk. Auto-assign by category, auto-reply with relevant KB articles, escalate tickets that sit too long, close stale ones. See our list of helpdesk automation ideas for more. Keep track of what these changes save you. When you ask for another hire, it helps to show which repetitive jobs you've already automated and what's still taking up the team's time. Set SLAs and show your numbers Once you have a few weeks of real data, define response and resolution targets and present them to business stakeholders. Be specific about what you can promise. "We'll respond within 30 minutes during business hours" tells people something useful. Promising to resolve every critical incident in four hours is harder to defend when you're waiting on a vendor. Our guide to SLA management covers how to set realistic ones, and ticket priority levels are the other half of the same conversation. Ask your users how it's going, too. Your resolution times can improve while people are still frustrated because they never get an update. Share what you heard and what you're changing. "You told us password resets were painful, so we added self-service reset" earns more goodwill than any satisfaction score. Growing into tiers You don't need tiers on day one. With three people, everybody does everything, and that's fine. Tiers start to make sense when the ticket data shows a clear split between quick, repeatable requests and long, specialist investigations, and when the specialists keep getting interrupted by the quick stuff. A typical progression looks like this: Everyone handles everything, but you track which tickets take minutes and which take days. A dedicated first-line person handles intake, routing and the quick fixes, using the knowledge base the team has been building. Everyone else gets fewer interruptions. Formal tier 1 and tier 2, with written escalation rules: what tier 1 must try before escalating, what information they attach, and how quickly tier 2 responds. Specialist queues (infrastructure, applications, security) once the volume justifies it. For a sense of how many people you'll need at each stage, see how big should your IT helpdesk team be. When you hire, hire for character first. You can teach someone Active Directory. Teaching patience, curiosity and the ability to stay calm with an angry user is much harder. We've written more about the skills good helpdesk staff need. Look after the team you have If a tech tells you they're falling behind, look at the queue with them. Work out what can wait, what someone else can take, and whether you need to tell users there's a delay. If admitting they're stuck earns them a lecture, next time you'll find out from an angry user instead. Give the team time to fix the things that keep slowing them down. That might mean leaving a few non-urgent tickets until tomorrow while someone sorts out the deployment script they've been fighting all month. A rough six-month plan These will overlap. Start writing down fixes as soon as you have somewhere to put them, and agree on urgent-ticket expectations early. The months below give you an order to work through, not deadlines to impose on a team you just met. Month 1: talk to everyone, read old tickets, record baseline numbers, fix one quick pain point for your techs, agree on goals and budget with leadership. Month 2: write down your scope, pick a ticketing tool, launch a simple portal with one "get help" button, enforce one front door. Month 3: review the notes you've collected, document the key SOPs with your techs, add the first request forms based on real ticket data. Month 4: automate the obvious things: onboarding and offboarding, password resets, software installs, ticket routing. Month 5: check whether you're meeting your response targets, ask users what's still frustrating them, and pick something to fix. Month 6: compare against your baseline, present the results, and use the data to make the case for the next hire or the first tier split. Six months in, you should be able to show what comes in, who's handling it, and where the team still needs help. You may still have two techs. At least you'll have something better than "we're busy" when you ask for a third.

16th Jul 2026 • 1 votes
Best AI helpdesk solutions in 2026

Every helpdesk vendor now sells "AI". What they actually ship differs a lot. Some offer a chatbot that answers customers before a ticket exists. Some offer a copilot that drafts replies for agents. Others hand you a platform and a consultant's invoice. The pricing models differ too: per seat, per conversation, per "resolution", or a pool of credits that nobody on the buying committee fully understands. We looked at six options, from a free do-it-yourself build to a full enterprise ITSM suite. Each one gets the same treatment: what it does well, where it falls short, and what it costs as of September 2026. Disclosure: this review is published on Jitbit's blog, and Jitbit is one of the products below. We tried to hold it to the same standard as the others, and we list its weaknesses too. Competitor prices come from public pricing pages and recent third-party breakdowns. Vendors change prices often, so check before you sign. How we evaluated Grounding. Does the AI answer from your documentation and ticket history, or from general model knowledge? Coverage. Does it deflect tickets (customer-facing), help agents (agent-facing), or both? Cost predictability. Can you forecast next quarter's bill without a spreadsheet model? Time to value. Days, weeks, or a multi-month implementation project? 1. Homegrown & Free: a Copilot Studio agent grounded on SharePoint Best for: internal IT support in organizations that already run on Microsoft 365. This option gets overlooked because nobody sells it. If your company already lives in Microsoft 365, you can build a decent self-service IT assistant in an afternoon without buying a helpdesk. The recipe is simple: put your end-user documentation on one SharePoint site, point a Copilot Studio agent at it, and publish the agent to Teams, where your employees already spend the day. Here is how to do it well. How to set it up Create a dedicated SharePoint communication site, for example "IT Help". Keep the knowledge the agent will use on this one site, not scattered across team sites. A single, clean source gives better answers than a large, messy one. Write one page per problem. "Reset your VPN token", "Printer on floor 3 shows offline", "Request a new laptop". Use the error message or symptom a user would type as the page title, and put the fix in numbered steps. Retrieval works on chunks of text, so short focused pages beat a 60-page PDF manual. Avoid scanned PDFs and screenshots-only pages, because the agent cannot read text inside images reliably. Check permissions. The agent answers using the identity of the person asking, so it only sees what that person can see in SharePoint. Give all employees read access to the site. Keep admin-only runbooks on a separate site so they never leak into employee answers. Create the agent in Copilot Studio (copilotstudio.microsoft.com). Add the SharePoint site URL as a knowledge source, and keep authentication set to "Authenticate with Microsoft", which SharePoint knowledge requires. Turn off general knowledge. In the agent's generative AI settings, disable the option that lets the model answer from its own general knowledge. You want "I don't know" rather than a confident, invented fix for your internal VPN. Write short instructions. For example: "You are the IT help assistant for Contoso employees. Answer only from the IT Help site. Give numbered steps. If the answer is not in the documentation, say so and link to the ticket form." Add an escalation path. Change the fallback topic so unanswered questions end with a link to your ticket form or IT mailbox. More advanced teams add an agent flow that opens a ticket directly, but each tool call uses extra credits. Publish to Teams and Microsoft 365 Copilot, then pin the agent in Teams for all employees through the Teams admin center. If people have to look for the agent, adoption stays low. Review analytics every week. Copilot Studio shows which questions went unanswered. Each one is a missing SharePoint page. Write it, and the agent improves by the next morning. This loop matters more than anything else on this list. Pros. There is no new vendor, no procurement cycle, and no new login. Employees ask questions in Teams, where they already are. Identity, permissions and compliance come from your existing Microsoft tenant, so security review is short. The knowledge base is ordinary SharePoint pages that anyone in IT can edit, with no proprietary format to migrate later. For the large share of internal tickets that are really "how do I..." questions (password resets, VPN, printers, Wi-Fi, software requests), a well-written site plus a grounded agent can deflect a meaningful share of volume in the first month. Cons. This is a self-service answer engine, not a helpdesk. There is no ticket queue, no SLA tracking, no assignment, no reporting on agent workload, and no audit trail of who fixed what. When the bot can't help, the issue goes to email or a form, and you still need something to manage it. Answer quality depends entirely on the documentation. A thin or outdated SharePoint site produces thin or outdated answers. Copilot Studio's credit-based licensing is also hard to forecast, and agents can be disabled automatically once a tenant goes 25% over its prepaid capacity. It works for employees only. Do not try to turn it into a customer-facing support bot. Price. Effectively free if your users already have Microsoft 365 Copilot licenses. Microsoft does not charge credits when licensed users talk to employee-facing agents, within fair-use limits. Without those licenses, Copilot Studio bills in credits: $200 per month for a pack of 25,000, or $0.01 per credit pay-as-you-go through Azure. A generative answer grounded on a knowledge source costs 2 credits. With the optional tenant-graph grounding it costs 12. In practice, that is roughly two to twelve cents per answer, and a few hundred dollars a month covers a mid-sized company's internal IT questions. The real cost is the staff time to write and maintain the SharePoint pages. You would need that documentation with any tool on this list anyway. 2. Jitbit Helpdesk Best for: mid-sized support and IT teams that want a full ticketing system with AI included, not billed separately. Pros. AI is built into the ticketing workflow, not added as a separate product. An AI assistant panel in every ticket drafts replies grounded on your knowledge base, indexed external documentation, canned responses, and similar closed tickets. It also summarizes long threads, cleans up agent drafts, and turns solved tickets into new KB articles, which helps teams that are just starting a knowledge base. Automation rules can run AI triage on every incoming ticket (sentiment, category and priority in one pass) and can post first-line AI replies either directly to the customer or as internal notes for review. The live chat widget has an AI auto-responder that hands off to a human when the visitor asks for one. For technical teams, the AI can call your own HTTP endpoints or MCP servers, so it can look up an order status or a subscription without an agent. Model choice is unusually open: GPT and Gemini are included, or you can bring your own key for Claude, Azure OpenAI or AWS Bedrock. That matters for data-residency and HIPAA reviews, and Jitbit signs a BAA on its Enterprise plan. It is also one of the few products here that still offers a self-hosted, on-premise edition with the same AI features. Cons. Jitbit is a smaller vendor, and its integration marketplace is much smaller than Freshdesk's or ServiceNow's. Its customer-facing bot is a helpful extra on top of a helpdesk, not a dedicated conversational platform. Teams with very high chat volume in B2C, which is Fin's specialty, will find fewer controls for multi-step procedures and channel orchestration. Like every grounded AI, it only performs as well as the knowledge base behind it. On-premise customers who want semantic search and document indexing must run an extra Docker-based add-on, and they supply their own model API keys. The entry-level Freelancer plan does not include AI credits. Price. Flat plans with no per-resolution or per-session fees: Freelancer $29/month (1 agent), Startup $69/month (4 agents), Company $129/month (7 agents), Enterprise $249/month (9 agents, $29 per extra agent). Annual billing saves about two months. Unlimited AI credits are included from the Startup plan up. For a seven-agent team, that works out to about $18 per agent per month with AI included. On most of the other paid products here, AI alone costs more than that per agent. 3. Fin (by Intercom) Best for: high-volume customer-facing support where deflection rate is the main metric. Pros. Fin is arguably the most capable customer-facing AI agent on the market, and it is the product the rest of the category measures itself against. It handles multi-turn conversations well, follows written "procedures" for multi-step tasks such as refunds or account changes, and works across chat, email, and voice. Importantly, Fin does not require Intercom's helpdesk. It can run on top of Zendesk, Salesforce, Freshdesk, Front, and others, so you can add it to an existing stack without migrating. Its reporting is built around resolution rate, which makes the ROI case easy to present to a CFO. Cons. Outcome-based pricing is fair in theory and hard to budget in practice. Fin counts an "assumed resolution" when a customer simply stops replying after its last answer. That includes customers who gave up. Your bill grows with volume, not with headcount, so a seasonal spike or a product incident that floods support also increases your AI spend. Fin is built for customer-facing deflection. Agent-side features are stronger inside Intercom's own inbox, so standalone deployments on other helpdesks get less of the product. For internal IT support, it is the wrong tool. Price. $0.99 per billable outcome (a resolution, a procedure handoff or a disqualification), and $9.99 per qualified sales lead. Running standalone on another helpdesk has a minimum of 50 outcomes a month. Inside Intercom, you also pay for seats: Essential $29, Advanced $85, or Expert $132 per seat per month on annual billing. A ten-seat Advanced team resolving 2,000 conversations a month pays roughly $2,800, and about 70% of that is Fin. 4. Tidio (with Lyro AI) Best for: small e-commerce stores that mainly need a website chatbot. Pros. Tidio is one of the fastest ways to get an AI chatbot onto a website. Lyro, its AI agent, learns from your FAQ and site content in minutes, and setup takes almost no technical skill. It integrates well with Shopify, WordPress, and the common e-commerce stack, so it can answer order and shipping questions that make up most of a small shop's inbox. The visual Flows builder handles cart-abandonment nudges and lead capture alongside support. For a one- or two-person store, the free tier is enough to try it before paying. Cons. Tidio is chat-first, and the ticketing side is basic. There is little in the way of SLAs, complex routing, asset management, or the reporting a growing support or IT team eventually needs. Lyro is billed by conversation, and the free and Starter plans include only 50 Lyro conversations in total, not per month. After that, it stops answering. The plan structure has a big gap: the jump from Growth to Plus is more than tenfold, with no middle tier. Teams often report that real costs run two to three times the advertised price once AI and Flows add-ons are included. It is not designed for B2B, internal IT, or regulated industries. Price. Starter $29/month, Growth from $59/month (scaling to about $349 depending on volume), Plus $749/month, and Premium from $2,999/month. Lyro AI is a separate add-on starting at $39/month, and Flows costs another $29/month. A typical Growth setup with Lyro and Flows costs around $127/month before overages. Annual billing saves about 17%. 5. Freshdesk (with Freddy AI) Best for: mid-market customer support teams that want a mainstream, feature-complete suite and can live with add-on pricing. Pros. Freshdesk is a mature, full-featured helpdesk with omnichannel support, a large app marketplace, solid automation, and a familiar interface that new agents learn quickly. Freddy AI covers both sides of the job. The Freddy AI Agent deflects questions on chat, email and the web widget. Freddy Copilot helps human agents with reply drafts, summaries, tone adjustment and suggested solutions. Freshworks also sells Freshservice for internal IT, so organizations can standardize on one vendor for both customer and employee support. Cons. AI costs are split across several meters and plan requirements. Copilot is available only on Pro and Enterprise, so Growth customers cannot buy it at any price. The customer-facing AI Agent is billed by session, and unused sessions expire at the end of each billing cycle instead of rolling over. Freshworks raised plan prices in 2026 for the first time in five years and cut the free plan to a six-month program for one or two agents. Model choice and on-premise deployment are not available. Price. Growth $19, Pro $55, Enterprise $89 per agent per month (annual billing). Freddy Copilot adds $29 per agent per month ($35 on monthly billing). The AI Agent includes 500 sessions, then costs $49 per 100 sessions. The realistic entry point for agent-side AI is $84 per agent per month (Pro plus Copilot). A five-agent team on Pro with Copilot and moderate bot usage spends roughly $650-700 a month. 6. ServiceNow (with Now Assist) Best for: large enterprises running IT, HR and facilities service management on one platform. Pros. ServiceNow is the default choice for enterprise ITSM, and its AI benefits from being close to all of that data. Now Assist summarizes incidents, drafts resolution notes, generates KB articles from resolved cases, and powers a Virtual Agent that can complete requests end to end instead of just answering questions. Because it sits on the same platform as the CMDB, change management, and HR and facilities workflows, the AI can act on real records: reset an account, provision software, or open a change request. No other product here offers that level of process depth, governance, and audit trail. In 2026 ServiceNow moved to AI-native tiers, so AI is now included by default rather than sold as a separate SKU. Cons. Cost and complexity. Implementations usually take months and a certified partner, and the platform typically needs dedicated administrators after go-live. Pricing is quote-only and heavily negotiated, so two companies of the same size can pay very different amounts. AI usage now draws from consumption-based "Assist" pools, which adds another capacity figure to forecast and renegotiate. For organizations under about a thousand employees, ServiceNow is usually more platform than they need. Price. There is no public price list. In April 2026, ServiceNow replaced its Standard/Pro/Pro Plus/Enterprise tiers with Foundation, Advanced and Prime, and older SKUs reached end of sale in mid-2026. As a reference point, legacy ITSM Pro licenses were widely reported at around $100-135 per fulfiller per month. Adding Now Assist (Pro Plus) raised that by an estimated 50-60%, to roughly $200-215 per fulfiller per month. Minimum seat commitments, platform fees and implementation services often make the first-year total a six-figure amount. Side-by-side Solution Best fit Pricing model AI included? Copilot Studio + SharePoint Internal IT, Microsoft shops Credits, or free with M365 Copilot licenses Yes (it's only AI, no ticketing) Jitbit SMB and mid-market support and IT Flat monthly plans Yes, unlimited from Startup plan Fin High-volume customer support $0.99 per outcome, plus seats in Intercom It is the product Tidio Small e-commerce Plan plus Lyro conversation add-on Add-on from $39/month Freshdesk Mid-market customer support Per agent, plus Copilot seats and bot sessions Add-on, $29/agent plus sessions ServiceNow Large-enterprise ITSM Quote-only, per fulfiller, plus Assist pools Bundled in 2026 tiers The bottom line Start with the question you're really trying to answer. If you want employees to stop emailing IT about VPN passwords and you already pay Microsoft, build the SharePoint and Copilot Studio agent first. It costs almost nothing, and the documentation you write for it will make any helpdesk you buy later work better. If you need an actual ticketing system with AI included and a predictable bill, Jitbit and Freshdesk are the main choices, and they differ mostly in how AI is charged. If deflecting a large volume of customer chats is the whole goal, Fin sets the standard, as long as you are comfortable with a bill that grows with volume. Tidio fits small online stores. ServiceNow fits organizations large enough to need a service-management platform, with a budget to match. Whatever you choose, AI quality comes from your knowledge base, not the model. Every product here gives better answers with better documentation, so start writing it now.

27th Jun 2026 • 1 votes
Jitbit Helpdesk Bot is now in the Microsoft Teams Store

Our new Microsoft Teams app just passed Microsoft's certification and is live in the Teams Store: Jitbit Helpdesk Bot. Search "Jitbit" in the Teams app store and it's right there - no custom app uploads, no admin-center gymnastics. Unlike our old webhook integration (one-way channel notifications, now deprecated), this is a proper two-way bot: End users create tickets in chat - type new and get a real form with category and priority, or turn any Teams message into a ticket from the "..." message menu. my tickets lists your open requests Technician replies come back to Teams - as cards with an inline answer box, so the whole conversation can happen without opening the helpdesk Channels get actionable ticket cards - @mention the bot, type subscribe, and every new ticket shows up with Take it / Reply / Close buttons. Cards update in place when the ticket changes - whether that happens in Teams or in the web app Setup takes about two minutes: install the app, click "Generate pairing command" on the helpdesk admin page, paste the command into a chat with the bot. Users are matched by their Microsoft 365 email automatically. Self-hosted customers run their own private bot, so ticket traffic never touches our servers. The bot is included with all plans. Details and setup steps: the integration page and the documentation.

8th May 2026 • 1 votes
Top 20 Helpdesk Interview Questions (with answers)

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.

8th Mar 2026 • 1 votes

More in programming

My new digital home

It's time for a dev blogger's favorite topic: blogging about my new blogging setup. After migrating my blog from Hexo to Eleventy, building a photography website and creating a personal one-pager, it was time to find a new digital home for all my projects. If you notice any issue after the migration, please let me know. I redirect the RSS feed to the new domain, but you might want to update the feed URL in your reader. Motivation I've been maintaining three different websites under two different names: a mostly developer-oriented blog, a photography portfolio and a one-pager gluing everything together. When I started blogging about my sabbatical journey, I was thinking about making yet another page to create a clear separation. I've decided to do the opposite and merge all my websites into one instead. As I further reduce my dependency on social media and third-party services, it has become even more important to have my own space and practice POSSE. Every decision I've made was driven by two main goals: simplicity and personality. Setup I've stopped chasing the latest and greatest. I want to keep the setup as clean as possible, which means pulling fewer dependencies. Every package adds complexity and maintainability costs, so I've only added what was necessary — no more Gulp, Sass or Tailwind. Instead of taking one of my existing websites as a starting point, I created this project from scratch. I reused some of my previous code, but I didn't want to take over any technical debt (especially with the advancements in CSS). The foundation of this website hasn't changed: Eleventy (Build Awesome). It covers the fundamentals of a static site and offers a great level of customization. I've made my project more and less dependent on Eleventy at the same time: I replaced Gulp as my build pipeline with pure Eleventy processing. I replaced most shortcodes with Markdown alternatives (and markdown-it plugins), which are better supported by editors like Obsidian. I've also replaced the Nunjucks template engine with Liquid, which comes with a few trade-offs. The main reason was to avoid creating a new collection for every set of posts I render. With Liquid, you can apply array functions like filtering or sorting in the template itself: {% assign drafts = collections.all | where: "data.isDraft" | reverse %} {% for draft in drafts %} … {% endfor %} Another advantage is having date formatting included, so I don't need another library or custom code. You can even set a default date format, so you don't have to provide it each time. What I don't like is the verbosity of the template language, although I've gotten used to it by now. Nunjucks: {{ "/tags/" + tag + "/" }} {{ modified or created or date }} {% set perspectives = ["dev", "photography", "life"] %} Liquid: {{ "/tags/" | append: tag | append: "/" }} {{ modified | default: created | default: date }} {% assign perspectives = "dev, photography, life" | split: ", " %} After migrating my existing content, I've noticed the build taking way too long, both in the dev server and the production build. I've found out that the Eleventy template cache is turned off for Liquid by default. This was useful during development, but when updating actual content, it caused every template and partial to be constantly recalculated. After turning the cache on, this issue was resolved: eleventyConfig.setLiquidOptions({ cache: true }); Check the colophon for the full tech stack overview. Perspectives The main challenge was finding a way to separate and present my main personas. The Venn diagram intersection of people interested in software development, photography and my personal life is probably small. I could use tags, but they don't offer the level of personalization I was looking for. Most personal blogs separate the content by post type (blog post, note, photo), but this doesn't fit my use case. Instead, I've decided to structure my website around three perspectives, a term I have borrowed from the Eclipse IDE. Each perspective comes with its own avatar, tagline and bio. If someone is interested in everything I share (hi Mom!), they can still view all my posts. Design Since building my photography website, I've made many changes, but I never got around to share an update. The biggest change was the design, which I have used as a blueprint for the new website. I've decided to mimic a social timeline/feed, which most people are familiar with. At the same time, it should be clear that it's a personal website and not yet another walled garden. Typography is an important part of every design. The first step is to choose between a system font stack and a custom font, which comes with the usual performance vs. personality trade-offs. I've decided to go with a uniform look across all devices. I've settled on Source Sans 3 for copy text and Hack for code. Another big change was introducing a sidebar. I always felt like the empty horizontal space was "wasted" on a desktop device, but getting the sidebar UX right is challenging. I'm happy with the result, especially with the last two panels adding a personal touch to the design. Images I've made several changes to the handling of image files. To make them compatible with Markdown editors, I had to replace my custom picture shortcode. The official Eleventy image plugin is a popular choice, but it violates my simplicity goal and doesn't support everything I needed. I've decided to go with a plain Markdown image markup and a single image file (no format fallback or 2x version for retina displays). Additionally, I wrote a markdown-it plugin to turn the optional title parameter into a caption. As for the file format, both WebP and AVIF have excellent browser support. For each image, I select the format based on the quality and file size. For my photos, I'm using WebP for the timeline thumbnails and JPG for the full-size version. Theme picker There have been some recent discussions about dark mode toggles, and I considered going for a light/dark solution based on the user's OS preference. Driven by the personality goal, I knew I had to add at least one more theme, so a proper theme picker was necessary. Similar to navigation, people like to hide the theme selection on mobile devices behind a burger menu or a dropdown. I prefer the solution by Sarah L. Fossheim, where all available themes are displayed above the page footer. A friend was scrolling through my new website, and their first question was "Why is the theme picker in the footer?". This tells me the solution was a good idea — I don't think he would have noticed a typical theme button in the header. The implementation follows standard practices: Use the light or dark theme as default based on the user's OS or browser preference. Store a selected theme in the local storage and use it as the single source of truth. Prevent a flash of inaccurate color theme. Make the theme play nicely with bfcache. I might have slightly gone overboard with my third theme, but the nostalgia kept me adding more and more features. Enjoy going back to the 90s: Feeds As browser vendors decided to remove XSLT support, I didn't bother to style my feed. Instead, I've created a new web feeds page, listing all available feeds and a short explanation. I provide one feed for every perspective and one with all my posts combined. I once offered tag-based RSS feeds. This was useful for my sabbatical, but even there I had only a single subscriber. Now, all tag feeds redirect to their main perspective feed. I've also dropped the JSON feed, despite having at least 16 subscribers. Given that every web feed reader supports Atom feeds, I don't see the value of providing a JSON alternative. A JSON feed doesn't add much complexity, but handling different media types (post, photo) and properly escaping the content is one more thing to implement and maintain. Quality assurance I've put a lot of effort into my new digital home, and I want to make sure it stays in good shape. I've included several tools, most running automatically as part of the CI pipeline: eleventyDataSchema — lint Eleventy data values like titles or dates markdownlint — format/lint Markdown files Vale — lint content (grammar, writing style, formatting) Lychee — find broken links (internal and external) Evaluatory — check accessibility and validate HTML Oxlint — lint JavaScript files Eleventy linters are another option to analyze a template's output, but I haven't found a use case for it yet. Not everything can be automated, so I also did the following manually: Test with Chrome, Firefox and Safari Test with Polypane Test with Google Lighthouse Test with a screen reader Test with JavaScript disabled Test with CSS disabled Test at 200% zoom Test with a bigger browser font size Test with custom fonts disabled Test with delayed assets Performance It's difficult to compare the performance of two separate websites with that of a combined one. Some parts got worse, e.g. bigger font files and more CSS. At the same time, I've noticed that gzip compression was turned off for anything but HTML for a few years now (I must have missed it when upgrading nginx) 🙈. One improvement was to implement on-demand assets. For example, the lite-youtube-embed CSS and JavaScript is only loaded if a <lite-youtube> element is present on the page. As before, JavaScript is fully optional (except for interactive demos in individual posts). I've been using a mix of <noscript> and CSS to hide elements that require JS (like the theme picker). I don't like the user experience of pagination, so I avoided it for years. But now that I have almost 300 posts, I've decided to finally add it. I display 30 posts per page, with images further down still being lazy-loaded for better performance. I haven't applied pagination to tag pages, as that's more complex with Eleventy. Bits and pieces Here are some other noteworthy changes: I've removed post-specific social share images and use a single WebP Open Graph image instead. I've dropped JSON-LD. Open Graph and microformats are sufficient. "Naming is hard" is a common expression in software development, but it also applies to photograph titles. I've decided to use a counter as the title, e.g. #0100. Sometimes I do come up with a title that I love, like the Castle in the Sky, so I might mention it in the description. On a photo page, you can now open the previous/next photo using the left/right arrow keys (in addition to the existing navigation buttons). It's now possible to filter photos by date, gear, or location. Check the explore page for an overview. I've learned about and used some experimental CSS features (with progressive enhancement), like scroll-triggered animations or squircle corners. I've added an AI statement on my LLM usage. I finally have a proper about page. Cool URIs don't change, but it's inevitable when moving to a new domain. All my previous URLs are redirected, except for some assets that are no longer used. I will keep the old domain, so the redirects will continue to work for a foreseeable future. I've kept my previous Easter egg and added a few more. Have a happy hunt! 🕵️‍♂️ Inspiration I visited hundreds of personal websites looking for inspiration. Here are a few that I kept coming back to: Emma Goto. I love Emma's approach to presenting the variety of her interests, even though I went a different route. Brennan Kenneth Brown. This website has so much to offer. It's a great example of what the open web looks like. Rex Barrett. The sentence "Collecting hobbies is my hobby." hit home — so much that I had to steal borrow it for my short life bio. Conclusion This project was mostly about merging the content of two websites into one. I knew this would take a considerable amount of time, but I still greatly underestimated the effort. In the end, it was all about the journey, not the destination. I loved fine-tuning the design and tweaking little details that probably no one will ever notice. I still have many more ideas left in my backlog. How do you like my new digital home? If you have an opinion, let me know! Reply via email

4 hours ago • 1 votes
Industrial Growth

New electronica album by Warrington-Runcorn New Town Development Plan

4 hours ago • 1 votes
Verifying my web archives with Playwright

To protect against link rot and disappearing content, I save local copies of web pages I like into my web archive. Ideally, this archive is completely self-contained. I want a local copy of each page’s HTML and all the assets it depends on (CSS, images, scripts, and so on). I don’t want my archived pages fetching resources from the original website, which could disappear at any time. Initially, I was verifying self-containedness by hand. I’d open each saved page in a web browser, and check the browser dev tools. I’d check the Console tab for errors and failed requests, and watch the Network tab for requests going out to the internet. That approach was tedious and error-prone, and I wanted something better. I now automate the process using Playwright, a testing framework that allows you to control web browsers. I open each page using Playwright, and check if it’s making external requests. Detecting external requests in Playwright When you open a page in Playwright, you can subscribe to request events which tell you when the page issues a request. In this Python snippet, we start Playwright, start a WebKit browser, and open a new page. We tell the page to append external requests to a list, and then load example.com. We see that example.com makes two requests on page load: one for https://example.com, and one for a JavaScript file. from contextlib import closing from playwright.sync_api import sync_playwright with ( sync_playwright() as p, closing(p.webkit.launch()) as browser, closing(browser.new_page()) as page, ): requests = [] page.on("request", lambda msg: requests.append(msg)) page.goto("https://example.com") print("requests:", requests) # requests: [<Request url='https://example.com/' method='GET'>, # <Request url='https://example.com/s.js' method='GET'>] In a more complex scenario, we might use Playwright to interact with the page after loading – for example, clicking a button or filling in a form, and then we could see the requests triggered by each action. Once we have a list of requests made by the page, we can inspect the url property to check if any of them were fetching from an external website. I wrote a function is_external_request to carry out this check: from playwright.sync_api import Request import urllib.parse def is_external_request(req: Request, original_url: str) -> bool: """ Check if a request has a different origin than the original URL. A request is considered internal if: - it matches the original URL exactly - it has the same scheme, host, and port as the original URL - it uses a `blob:` scheme (for example, in-memory media representations) """ if req.url == original_url: return False # Compare the scheme/host of the request to that of the original URL. org_url = urllib.parse.urlsplit(original_url) req_url = urllib.parse.urlsplit(req.url) if org_url.scheme == req_url.scheme and org_url.netloc == req_url.netloc: return False # Ignore blob: URLs, which are in-memory representation of some data, # and not an external request. # # Playwright detects blob: URLs when loading media files; for example # using the <audio> or <video> tag. if req_url.scheme == "blob": return False # Fail open: if we can't decide if a request was internal or external, # assume it was external. return True assert_page_is_self_contained(ctx, url) I’ve wrapped these two steps in a function assert_page_is_self_contained(ctx, url), which is part of my chives utility library. The function takes a Playwright Browser (or BrowserContext) and a URL, then: Opens a new page in the browser Loads the URL in the page Checks what happened when the page completes loading It throws an exception if there are any: Uncaught page exceptions or errors Console warnings or errors Non-GET requests Requests targeting external resources The function tries to trigger important network requests that might be skipped on the initial page load. For example, it evaluates the body’s offsetHeight to force a synchronous reflow, which causes the browser to request any lazily loaded images or fonts that might otherwise be missed. Here’s an example which verifies a file example.html from the working directory: from chives.browser_fixtures import assert_page_is_self_contained, file_uri from contextlib import closing from playwright.sync_api import sync_playwright with ( sync_playwright() as p, closing(p.webkit.launch()) as browser, ): assert_page_is_self_contained(browser, url=file_uri("example.html")) I originally passed a Page as the first argument, but changing the function to take a Browser or BrowserContext lets it manage its own pages. It gets a fresh page for every verification, and closes it when it’s done. (The first time I ran this, I created a new page for every verification, and never closed them – my computer ground to a crawl as my script opened hundreds of browser tabs.) If you create a new context, you can emulate different browser settings, like location, locale, and window size. Here’s an example where we use contexts to test the same page in light/dark mode: with ( sync_playwright() as p, closing(p.webkit.launch()) as browser, ): with closing(browser.new_context(color_scheme="light")) as light_ctx: assert_page_is_self_contained(light_ctx, url=file_uri("example.html")) with closing(browser.new_context(color_scheme="dark")) as dark_ctx: assert_page_is_self_contained(dark_ctx, url=file_uri("example.html")) In my web archive, I check every page in light/dark mode, and at 1×/2× pixel densities. It takes at least a second to run each verification, so I cache the results. As I save new pages, they’re added to a verification queue, and I’m warned of any missing assets. Unsurprisingly, the first run flagged many missing fonts and images, which I added to my local archive. Every saved page now passes cleanly. Browser is best-effort, but may still miss things Even with automated testing, it’s difficult to guarantee a completely self-contained archive. Different instances of a browser might load different assets, and a single page load might miss different variations: Responsive images – web pages can offer different sizes of an image, and the browser chooses a specific size based on the current window dimensions Appearance settings – a browser might load different fonts or images depending on light/dark mode Interaction-dependent assets – a web page might have assets that are only required on hover or user action You can mitigate some of this by testing with multiple contexts or adding post-load interactions, but every step makes the process take longer. Fortunately, most of the pages I save are simple, blog-style pages where I’ve stripped out the JavaScript. For my specific use case, initial load verification is more than good enough. Other uses for this code There are other projects where it could be useful to intercept and audit the requests made by a web page: Verifying your Content Security Policy (CSP). The CSP header restricts what resources can be loaded by a web page, and you could check that your configuration has the correct effect. Auditing login screens. You could check that sensitive pages don’t load any external scripts, which mitigates the risk of credential theft via a compromised third-party. Testing analytics and tracking. You could script user flows, like a shopping cart checkout, and confirm that tracking events fire correctly. I don’t do much front-end web development, but Playwright has become a key tool in my toolbox. I read a lot about people using AI agents and MCPs to interact with websites, but I prefer Playwright. It’s more fiddly and requires explicit instructions, but it’s constrained, deterministic, and I never have to worry about it doing something unexpected. [If the formatting of this post looks odd in your feed reader, visit the original article]

6 hours ago • 1 votes
Print Sales, Costs, And Profit: 2026

It’s four years since I bought a printer. I thought I would provide an update on running costs, print sales, and profit. I’m happy to be completely transparent about all this as I know it can be difficult to figure this out if you are thinking of creating your own printing business. January 11th 2026, 11:30am All the photos here are work shot in the last twelve months. Year Four Investment? Nothing other than consumables this year. I did purchase a high-spec film scanner last year, detailed here, but don’t consider that as part of this. The scanner has paid for itself several times over, and it may become a factor in future years (see below). Income Income is made up of sales through a local gallery that I am part of, along with web sales: 5,940.- CHF - sales through the gallery 80.- CHF - sales through web shop = 6,020.- CHF total income Total income is down about 50% compared to 2025. Costs I had to purchase consumables (paper and ink), at a total of 957.- CHF. That cost is included in the total here under the “print consumables” category. January 11th 2026, 3:30pm Rental cost of space in the gallery was reduced due to having overpayments of rent and my loan to the gallery, from the previous year(s), paid back to me. -1,500.- CHF - rental cost of space in the gallery -957.- CHF - print consumables (paper, ink) -1,138.- CHF - framing/mounting/postage -1,135.- CHF - commission to the gallery -300.- CHF - web shop subscription 0.- CHF - stripe / paypal fees 0.- CHF - advertising (none this year) = -5,030.- CHF total costs Total costs are down by about 60% compared to 2025. Total Profit 6,020.- CHF total income -5,030.- CHF total costs = 990.- CHF total profit A Quiet Year? Actually an average year. The previous couple of years were outliers, due to large orders, so really I’m back to normal in terms of sales. The key factors in managing to generate a [small] profit this year were: 1) no longer having to pay back the loan used to finance the printer, and 2) reduced rental cost of space in the gallery due to a previous loan to it being repaid. Also having to spend almost 1,000.- CHF on ink this year ate into profit. This is probably a “once every three years” cost given the rate I print at. The principal cost is rental of space in the gallery - in a normal year this would be 3,000.- CHF. Essentially this means, given the material cost of printing and framing/mounting and commission to the gallery, I need to make about 5,500.- CHF of sales to break even. Solar Eclipse, August 12th 2026 That’s a grind. However I did receive two substantial orders at the end of October, which haven’t made it in to this year’s figures and should boost next year’s. Maybe even a good sign for the year to come? At least now the original investment loan is repaid, the printing costs cover themselves in most years. I may look at offering scanning services now that I have a high-spec film scanner, which could become a scan + print service. More thoughts about that next time.

20 hours ago • 1 votes
F1

George Russell driving down the main straight during FP2.

20 hours ago • 1 votes
📚 BoredReading

You seem to be enjoying this.

Join free to unlock everything.

Create free account

Already have an account? Sign in