What's new in Keeper.sh

A calendar feed is a link you hand to another app, or another person, so they can see when you are busy. Until now you had exactly one, covering everything you had connected, so the link you gave a client showed the same events as the one you subscribed to yourself.

Feeds are now named and you can keep as many as you need. Each covers the calendars you pick for it and carries its own event name settings, so a feed built for a client shows nothing but busy blocks while the one you use yourself keeps the real titles. Every feed gets its own page and its own link, in a field you can select and copy.

Feed links are not derived from anything about you — the token is generated without taking any input from your account — so knowing your email tells nobody the address of your feed. Free accounts keep one feed; keeping several is part of a paid plan.

Read more about what a paid plan adds.

Every connected calendar copied the same span of time, which is fine until one of them is a decade old. A calendar you joined for a single project would drag its whole history into the calendar you actually live in.

Each calendar now carries its own window, set separately for the past and the future: one week, one month, three months, six months, twelve months or two years. The default is one month back and two years ahead, which suits most people without any change. Narrowing a window is not cosmetic — Keeper.sh stops fetching outside it, so a source that was slow because it held years of history gets faster, and events already copied outside the new window are cleaned up rather than left stranded.

Changing a window does not wait for the next scheduled run. Saving it asks for a sync straight away, so widening a calendar to six months of history fills that history in rather than only collecting what arrives from then on.

Read more about what a paid plan adds.

An assistant connected to Keeper.sh could already read and write events, but not answer the question people actually ask it, which is when you are free.

Finding free time works out the open slots across everything you have connected, over a range you give it. It reads availability rather than counting events: something marked free, or marked as working elsewhere, does not block a slot, while busy and out-of-office do. Give it working hours and working days in a named timezone and "find me an hour on Thursday" stops offering you 6am.

The other two are about control. Syncing on demand clears the backoff on any source that had been backing off after errors and queues a push to every calendar you copy into, throttled to once a minute. Pausing stops a calendar syncing in both directions while leaving it connected and its settings intact. All three work over the REST API as well, so the same actions run from a script.

Read more about everything Keeper.sh does.

Repeating events are the ones a calendar gets wrong quietly. The original series copies across correctly, and then someone changes it — the weekly call moves an hour later, a date gets skipped, the whole thing shifts when the organiser changes timezone — and the copies carry on describing the old arrangement. Nothing errors, so nothing tells you the two calendars stopped agreeing.

Changes to a series now reach the copies. Editing the repeat rule updates them, skipping a single date removes that occurrence rather than leaving it stranded, and moving the series to another timezone moves every occurrence with it rather than shifting the first and leaving the rest behind.

Single occurrences are handled as their own thing. Moving next Tuesday's instance of a weekly meeting changes next Tuesday, and the rest of the series stays where it is — which is what the original calendar does, and therefore what the copy should do.

Read more about everything Keeper.sh does.

Not every calendar publishes all-day events properly. A good number of subscription links — conference schedules, school calendars, sports fixtures — describe a day off as a timed event that starts at midnight and ends at midnight the next day. It is technically the same span of time and it reads completely differently: instead of a quiet banner across the top of the day, you get a solid twenty-four hour block that buries everything else.

Keeper.sh can now recognise that shape and copy it as a genuine all-day event. It is a per-calendar setting rather than something applied everywhere, because the interpretation is a guess — a real event that happens to run midnight to midnight is rare, but it is not impossible, and the right answer depends on the calendar you are reading.

Turn it on for the subscription that keeps swallowing your week, and leave it off for the calendars that publish all-day events correctly to begin with.

Read more about everything Keeper.sh does.

Not every calendar server asks for a password the same way. Most accept the straightforward exchange Keeper.sh already used, but a good number of self-hosted and university servers expect digest authentication, where the server issues a challenge and the client answers with a hash rather than the password itself. Keeper.sh could not answer that challenge, so those servers rejected credentials that were perfectly correct.

Both schemes now work. When a server asks for digest, Keeper.sh completes the exchange and the connection goes through on the details you already had — nothing about how you enter them changes, and there is no setting to find.

Which scheme your server wants is recorded the first time it tells us, so later syncs answer correctly on the first attempt instead of getting turned away and trying again. If a server refused your details at the connect screen before, it is worth another go.

Read more about the calendars Keeper.sh works with.

Connecting a calendar used to end in a wait. The account was linked, the calendars were listed, and then nothing visibly happened until the next scheduled run came around — which on the free plan could be half an hour of staring at an empty destination wondering whether the setup had worked.

Connecting now triggers a sync straight away. Events start arriving while you are still on the page, which turns the first minute after setup from a question into a confirmation, and means a mistake in your mapping shows up immediately rather than after the delay.

The same applies when you change something that affects what gets copied. Adjusting which calendars feed a destination asks for a sync rather than waiting for the schedule to notice, so the thing you just changed is the thing you can go and check.

Read more about everything Keeper.sh does.

Reading a calendar answers half the question. The other half is doing something about it, so an assistant connected to Keeper.sh can now create an event, edit one, delete one, see the invitations waiting for a reply, and RSVP to them. It can also list your connected accounts and fetch the link to your combined calendar feed, which is usually the thing you actually want when someone asks for your availability.

Every one of those abilities is available directly as an API as well. A new API tokens page under Settings lets you create tokens and revoke them individually, so a script you wrote once can be cut off without disturbing an assistant you still use.

Free accounts include 25 calls a day, which covers a person checking their week and booking the occasional thing. Pro removes the cap on both assistant and API access.

Read more about what Pro includes.

Keeper.sh can now be added as a connector in Claude and other assistants that speak the same protocol. Once it is connected, the assistant can see which calendars you have linked, look up the events in a date range and a timezone you specify, and count how many fall inside it — so "what does my Thursday look like" is answered from your actual calendars rather than from whatever you last pasted into the conversation.

You approve the connection once, on a consent screen in your browser, and the assistant signs in with OAuth rather than holding a password. Access is yours to revoke at any point, and revoking it cuts the assistant off without touching the calendars themselves.

At launch this is deliberately read-only. The assistant can look and it cannot change anything, which is the right place to start for something that has your whole schedule in view and occasionally misunderstands you.

Read more about everything Keeper.sh does.

An all-day event is not a meeting that happens to last twenty-four hours, and treating it as one made a mess. A day marked off for travel arrived on the other calendar as a timed block running midnight to midnight, which pushed everything else down the day and made a week look far busier than it was. All-day events now stay all-day when they are copied, across Google, Outlook and CalDAV.

Availability travels with them. An event you marked free stays free rather than turning into a solid block, which matters for the things people put on a calendar to remember rather than to reserve time — a birthday, a deadline, a release date.

Out-of-office and working-elsewhere entries keep their type too. A week marked out of office arrives as out of office rather than as a wall of busy, so the calendar receiving it can show it the way it means to, and colleagues reading your availability see the difference between you being away and you being in back-to-back meetings.

Read more about everything Keeper.sh does.

By default a copy carries the name of the calendar it came from, which keeps the original title private but tells you very little when three calendars all feed the same destination. You can now write the title yourself, per calendar, using a template.

The template takes plain text plus two placeholders: the original event's name and the name of the calendar it came from. Writing "Work — {{calendar_name}}" labels every copy in a way you will recognise at a glance, while "{{event_name}}" passes the real title straight through for a calendar where privacy is not the concern.

Because it is set per calendar, one connection can pass full titles through while another shows nothing but a block. That is usually the shape people actually want: your own calendars readable, and the ones other people can see reduced to when you are busy.

Read more about everything Keeper.sh does.

The old site asked you to take a fair amount on faith. It said Keeper.sh synced calendars, and left the questions people actually have — which calendars, how quickly, what it costs, what happens to the contents of your events — to be discovered after signing up.

The rebuilt site answers those up front. There are pages for what it does and what it costs, the providers it works with are named rather than implied, and the privacy behaviour is stated plainly: what a copy carries by default, what a shared link shows, and what is never copied on any plan.

It is also honest about the shape of the product rather than only its best angle. The free plan's limits are written down next to the paid one's, and running Keeper.sh yourself is documented rather than buried, on the grounds that people who want to read the code before trusting it with their calendar should not have to go looking.

Read more about everything Keeper.sh does.

The old dashboard listed the accounts you had connected and left you to work out what was actually happening between them. That was tolerable with two calendars and confusing with five, because the thing you want to see is not a list of accounts but which calendar is copying into which.

The rebuilt dashboard is organised around those connections. Each one shows where events come from, where they land, and what is being copied, so checking that your work calendar is blocking out your personal one is a matter of looking rather than reconstructing it in your head. Each calendar has its own page for the settings that apply to it, instead of every option living in one long form.

Sync status is visible rather than inferred. You can see when a calendar was last read, whether the last run had a problem, and what that problem was — which turns "I think it stopped working" into something you can confirm in a few seconds.

Read more about everything Keeper.sh does.

Reading a Google calendar meant finding its secret iCal address and pasting it in — a link that is awkward to locate, easy to leak, and impossible to revoke without regenerating it. You can now connect the account itself and pick which of its calendars Keeper.sh reads.

Signing in also means Keeper.sh knows what it is looking at. It lists the calendars on the account by name, so choosing between a personal calendar and one shared with you is a matter of ticking the right box rather than working out which link belongs to which.

A calendar can now be both a source and a destination without feeding itself. Keeper.sh recognises the events it created and skips them on the way back in, so pointing two accounts at each other produces one copy in each direction instead of a loop that grows on every run.

Read more about everything Keeper.sh does.

Outlook could receive your busy time but not supply it. If your work calendar lived in Outlook — which for most people is exactly where it lives — the one calendar that most needed to block out your evenings could not be read at all.

Signing in with a Microsoft account now works the same way Google does. Choose the calendar you want read, and Keeper.sh keeps its busy time flowing to every destination you have set up. A single account can be both ends at once: reading your work calendar and receiving your personal one, in the same connection.

Both providers now run through the same sync path rather than each carrying its own. That is invisible when things work, and it is why a fix to how repeating events or timezones are handled lands for Google and Outlook together instead of being written twice.

Read more about everything Keeper.sh does.

Google and Outlook cover a lot of calendars, but not the Apple one on your phone or the Fastmail account you moved to. Both speak CalDAV, an open standard for calendar access, and Keeper.sh now connects to anything that speaks it.

Connecting takes your address and an app password rather than your real one — a separate credential you generate for a single application and can revoke on its own, without changing the password you sign in with. The connect dialog links to the page where iCloud and Fastmail issue them, because both bury it somewhere different.

Once connected, a CalDAV calendar behaves like any other source. It is read on a schedule, its busy time reaches your other calendars, and it can be a destination as well as a source, which means a self-hosted or standards-compliant server works without Keeper.sh needing to know the product by name.

Read more about the calendars Keeper.sh works with.

Most calendar apps will hand you a subscription link, and that is now all Keeper.sh needs. Give the calendar a name, paste the link, and its events start arriving. Added calendars are listed on the integrations page and can be removed again at any time.

Some of those links are not public. Keeper.sh detects when a link asks for credentials and prompts you for a username and password rather than failing with nothing to act on, so a work calendar behind basic authentication connects the same way a public one does.

When an import does fail, the error says what actually went wrong — the link was unreachable, the credentials were refused, the file was not a calendar — instead of reporting a generic failure. Keeper.sh then refetches on a schedule, so what it holds stays in step with the calendar you pointed it at.

Read more about everything Keeper.sh does.

Connect a Google account and Keeper.sh writes your busy time straight into that calendar. Nothing is copied wholesale, though: you choose which of your connected calendars feed it. Events from a source you have not mapped to that destination are filtered out rather than written and cleaned up afterwards.

That mapping is the part worth setting deliberately. A work calendar can feed your personal one without the reverse being true, and a shared calendar you only read can stay out of both. Each pairing is its own choice, so copying runs one way unless you set up the other direction as well.

Keeper.sh tracks every event it creates at the far end. As your sources change, the copies it made are updated or removed to match, which is what keeps the destination an accurate picture rather than an accumulating pile of stale blocks.

Read more about everything Keeper.sh does.

Writing your busy time into another calendar is one way to stay out of double bookings. Handing someone a link is the other, and Keeper.sh now publishes one that covers everything you have connected at once.

Copy it from the integrations page and subscribe to it anywhere that accepts a calendar URL — another calendar app, a scheduling tool, a colleague's client. What arrives is your busy time from every source combined, rather than one subscription per calendar and the job of keeping that list current.

The link carries availability, not detail. Someone reading it can see the hours you are unavailable without seeing what you are doing in them, which makes it something you can share outside the people who already have access to your calendars.

Read more about everything Keeper.sh does.