Getting started with VOEvents

Have you ever wondered how astronomers share information between telescopes about rapidly evolving sources? Do you want to track gamma-ray bursts and stellar flares as they happen, maybe even point your telescope at them? Then you might be interested in VOEvents, and our new Python toolbox for dealing with them…

[Update April 2015: This post gives a gentle introduction to VOEvents. If you just want the technical details, see the new page about our VOEvent broker and how to connect to it.]


The VOEvent protocol can be used for passing alerts around a distributed, decentralized network of nodes.

The VOEvent protocol can be used for passing alerts around a distributed, decentralized network of nodes.
Image reproduced from J. Swinbank, Comet: A VOEvent broker, Astronomy and Computing,

The VOEvent (Virtual Observatory Event) standard defines a common format for astronomers to exchange information on transient astronomical events, for example supernovae explosions, gamma-ray burst detections, accretion flares and other things that go bump in the night. For many years, astronomers have exchanged information about exciting recent observations through the Astronomer’s Telegram and similar sources, but these are composed of unstructured, natural text – that is, written by humans – which means that to be reliably understood, they need a human to read them.

This is a problem for two reasons: first, it’s cruel to make humans watch a web-page for interesting new events twenty-four hours a day, even if they are just a PhD student. Second, we’re on the cusp of experiencing a ‘flood’ of astronomical transients. Until now, astronomers have observed perhaps a few interesting events per day, through a combination of satellites such as Swift and ground-based projects like CRTS and OGLE, but this rate is ramping up – the GAIA satellite is now releasing a steady stream of alerts, and projects such as LSST promise millions of events every night. So it’s clear that automated solutions are needed to keep up.

The best known such solution in the astronomy community is probably the NASA gamma-ray co-ordinates network (GCN). NASA-GCN has been operating for many years now, and the ground-breaking response speed of fully-robotic follow-up gave us decisive proof on the nature of GRB-progenitors as extragalactic sources, showing them to be some of the most energetic events in the universe. However, the original system has some fundamental limitations – all the alerts come directly from NASA, and there’s no way to feed back information into the network from other observatories without resorting to writing telegrams again. This is where VOEvents come in.

The VOEvent standard is designed around the idea of a decentralized, peer-to-peer network. This has two major advantages. Firstly, if one machine has an outage, the rest of the network can carry on swapping messages between themselves. Second, it’s much easier to start feeding messages back into the network from your very own robotic telescope. This opens up a whole new world of possible small-and-large telescope collaborations – for example, we might use a small optical telescope to decide which gamma-ray burst targets from Swift look the most promising for radio follow-up, and in fact we’re doing just that here at 4 Pi Sky.

You might be asking why, if VOEvent is so great, you haven’t heard of it before (unless you’ve been following LSST closely, in which case you’ll know it’s been chosen as their standard for releasing alerts). I think there are two main reasons for this. The first is the age-old chicken-and-egg problem. If no-one is publishing VOEvents, then no-one has any reason to subscribe to VOEvents. While there have been a few VOEvent nodes available in the past, the network effect has never quite taken off to date. We’re doing our best to try and ‘re-seed’ the network – we’re currently running an open-to-all-subscribers VOEvent node at It’s a little-known fact that NASA-GCN alerts are now also available in VOEvent format, so we’re currently rebroadcasting these, plus a few follow-up notices of our own, and we’re working closely with a couple of projects with the aim of adding more alert streams to the network in the near future.


The fourpiskytools package makes it easy to start sending or receiving VOEvent packets.

The second reason for slow uptake of the VOEvent standard is, perhaps, one of tooling. When we started putting together the 4 Pi Sky project, getting connected to the VOEvent network, and better yet actually doing something with the VOEvents, was a somewhat arcane process with patchy documentation. It’s this issue that we’ve been trying to address most recently. Guessing that most astronomers prefer getting to grips with code by working through an example, we’ve put together a simple Python package to get you started with VOEvents, built on John Swinbank’s Comet broker (which provides the connection to the VOEvent network) and our very own voevent-parse package (for accessing the data stored in VOEvent packets).  It’s called fourpiskytools, and aims to make it easy to start receiving and sending VOEvents. On a typical Linux installation, a couple of one-liner python install commands should be enough for you to start getting desktop notifications for each VOEvent received – so why not try it for yourself?

We look forward to hearing from your robots!