The Software Engineer’s Guide to Satellite Systems and Orbital Mechanics

Why the Physics of Falling Matters More Than You Think

A Battery alert at 3:00 A.M.

ALERT: Battery State of Charge < 20% — Satellite OBSAT-3

If you’ve spent any time on an on-call rotation, you already know what to do. Adrenaline shows up before your brain does. You sit up, grab your laptop, and start typing the incident-response commands you’ve typed a hundred times before. Low battery sounds like a five-alarm fire. Batteries dying means the spacecraft is losing power, and a spacecraft that loses power is a spacecraft that goes silent permanently, if you’re unlucky.

So you open the dashboard. Sure enough, the state-of-charge graph is sloping downward, sharp and unmistakable. Your instinct says: page the team, prep the safe-mode command, start drafting the incident report.

“Eclipse Status.” And it says:

IN_ECLIPSE: true

Every satellite in low Earth orbit spends part of each orbit sometimes as much as 40% of it passing through Earth’s shadow, just like the Moon does during a lunar eclipse, except this happens roughly every 90 minutes instead of once every few years. During that time, the solar panels produce nothing. Zero. The spacecraft runs entirely on its batteries, and the battery percentage drops the same way your phone’s battery drops when you unplug the charger except this “unplugging” happens on a rigid, predictable, physics-mandated schedule. In a few minutes, the satellite will cross back into sunlight, the panels will start producing power again, and the batteries will recharge. This happens, without fail, on every single orbit, since the day the satellite launched. It will keep happening until the satellite reenters the atmosphere at the end of its life, which is typically years from now.

You didn’t need to page anyone. You needed one more line of context on your dashboard, and more importantly you needed to understand why that line of context existed at all.

The central idea is that you cannot build good software for satellites without understanding the physics that satellites live inside of. Not because you need to become a physicist, but because the physics is the environment your software runs in the same way a backend engineer needs to understand TCP retransmission or a database engineer needs to understand disk I/O. Orbital mechanics is the “networking layer” of space software. Ignore it, and every dashboard you build will be a beautiful, well-engineered machine for generating false alarms.

That 3 a.m. page is also the moment I started sketching what would eventually become an idea I call Orbitlogs, not a product pitch, just a working title for a question that kept nagging at me: what would an observability platform look like if it actually understood orbits? We’ll come back to that idea later.

Why Software Engineers Should Learn Orbital Mechanics

If you’ve built systems for the cloud, you already have strong intuitions about distributed systems: latency, partitions, retries, eventual consistency, the CAP theorem, the general chaos of machines talking to other machines over unreliable networks. Those intuitions are extremely valuable. They will also, in a few specific but important ways, mislead you when you start working on spacecraft software.

Here’s the core difference, stated as plainly as I can put it:

Cloud infrastructure is a system you can usually reach. A satellite is a system you can only sometimes reach, that is always moving, and that is governed by a set of physical laws you cannot patch, cannot redeploy, and cannot override.

A few concrete contrasts:

Almost every anomaly in satellite telemetry needs to be interpreted relative to where the satellite physically is in space and time. A CPU temperature spike on a web server is a story about software. A CPU temperature spike on a satellite might be a story about the satellite having just rotated its solar-panel-covered face directly toward the sun after being in shadow for twenty minutes. Same-shaped graph. Completely different story.

This is why telemetry without orbital context is, quite literally, incomplete data. You are missing an entire dimension — the physical state of the spacecraft in its orbit — that explains a huge fraction of the variance you’ll see in every other metric: power, thermal, communications, even certain kinds of sensor noise. Traditional observability tooling (built for web services, born out of companies like Google, Netflix, and Datadog) was never designed with this dimension in mind, because a web server doesn’t orbit anything. A satellite does. That’s the whole ballgame.

So: why should a software engineer learn orbital mechanics? Not to become an aerospace engineer. To become a better interpreter of the data your own systems produce.

Everything from here forward builds toward that goal.

What Is Orbital Mechanics, Actually?

Strip away the jargon and orbital mechanics is a surprisingly small idea:

Orbital mechanics is the study of how objects move when the only real force acting on them is gravity.

That’s essentially the whole field. Rockets are complicated. Satellites, once they’re in orbit and their engines are off, are one of the simplest physical systems humans have ever had to model — because there’s (almost) nothing acting on them except the pull of the Earth (or Sun, or Moon) beneath them. No friction, no air resistance to speak of (at most altitudes), no wind. Just gravity, and momentum.

Humanity didn’t develop orbital mechanics because of satellites — satellites came 300 years later. It was developed to answer a much older question: why do the planets move the way they do?

• In the early 1600s, Johannes Kepler, using an enormous and precise dataset of planetary observations collected by Tycho Brahe, discovered that planets don’t move in circles (as everyone had assumed for two thousand years) — they move in ellipses, and they move faster when closer to the Sun and slower when farther away. He wrote these down as three laws, purely from data, without knowing why they were true.
• In 1687, Isaac Newton answered the “why.” His law of universal gravitation showed that a single, simple force — proportional to mass, and falling off with the square of distance — perfectly explained Kepler’s three empirical laws. Newton didn’t just describe planetary motion; he explained any motion under gravity, including the motion of a cannonball, an apple, or, three centuries later, a satellite.

The remarkable thing — and this is worth sitting with for a second — is that the equations Newton wrote down to explain the orbit of Mars around the Sun are the exact same equations mission control uses today to predict where the International Space Station will be in six hours, or where a GPS satellite will be next Tuesday. There’s no separate “satellite physics.” A satellite is just a very small, human-made moon. It obeys the same laws as every large, natural moon and planet in the solar system.

This matters practically: it means mission control doesn’t need to constantly re-measure a spacecraft’s position by, say, bouncing radar off it every second. Instead, they measure the position and velocity precisely a handful of times, feed those numbers into Newton and Kepler’s equations, and the equations predict where the satellite will be — accurately — hours, days, or weeks into the future. This predicted trajectory is called an ephemeris, and it’s one of the most foundational data products in all of spaceflight. Every ground station scheduling system, every collision-avoidance system, and every piece of orbital observability tooling (including the eclipse indicator from our 3 a.m. story) is built on top of an ephemeris.

Did You Know? Kepler never used the word “orbit” the way we do, and he never knew why planets moved in ellipses. He found the pattern in Tycho Brahe’s data through years of laborious hand calculation — literally thousands of pages of arithmetic — before Newton supplied the underlying cause seven decades later.

Understanding Gravity, From Scratch

Let’s build intuition before we touch a single equation.

Gravity is the tendency of any two masses to attract each other. Not just Earth pulling on you — you are also pulling on the Earth, and on your coffee cup, and on the person sitting across from you. The reason you don’t notice these smaller attractions is that gravity’s strength depends on mass, and everyday objects are laughably tiny compared to a planet. Earth’s mass is about 6 × 1⁰²⁴ kg. A coffee cup’s pull on you is real, but it’s about a billion-billion times weaker than Earth’s, so it’s undetectable without extremely sensitive lab equipment.

Mass vs. weight — these get conflated constantly, and the distinction actually matters for satellites:

• Mass is how much “stuff” something is made of. It doesn’t change based on where you are. A 100 kg satellite has 100 kg of mass whether it’s sitting in a factory in California or orbiting 400 km above the equator.
• Weight is the force gravity exerts on that mass, and it absolutely does change based on location. The same satellite “weighs” less in orbit than on the ground, because it’s farther from Earth’s center, and gravity weakens with distance.

Acceleration is the rate at which velocity changes — speeding up, slowing down, or changing direction all count as acceleration. Here’s the key insight Newton had: gravity doesn’t create a force that stops things — it creates acceleration toward the source of gravity. Drop a bowling ball and a feather in a vacuum (no air resistance) and they accelerate downward at exactly the same rate, regardless of mass. This was famously demonstrated on the Moon by Apollo 15 astronaut David Scott, who dropped a hammer and a feather side by side and watched them hit the lunar surface at the same instant.

Free fall is what you’re doing any time gravity is the only thing acting on you. Skydivers before their parachute opens are in free fall (though air resistance complicates it). And here’s the sentence that unlocks the rest of this:

Astronauts on the International Space Station are not “beyond gravity.” They are in free fall, exactly like a skydiver — they’re just falling so fast, sideways, that they keep missing the ground.

That single idea — falling sideways fast enough to keep missing the planet — is, quite literally, the entire secret of orbital motion. Everything else in this is elaboration on that one sentence.

Why do astronauts feel weightless, then, if gravity at the ISS’s altitude (about 400 km up) is still roughly 90% as strong as it is on the ground? Because “weightlessness” isn’t about the absence of gravity — it’s about the absence of a supporting force pushing back against gravity. When you stand on the ground, the floor pushes up on your feet just as hard as gravity pulls you down, and that push is what you feel as “weight.” In free fall, nothing is pushing back. You and the spacecraft around you are accelerating downward at exactly the same rate, so relative to the walls and floor of your spacecraft, you simply float. It’s the same reason the inside of a falling elevator feels weightless in the instant before it hits the brakes.

How Satellites Actually Stay Up There

Let’s do the thought experiment that Newton himself used to explain orbits — it’s called Newton’s Cannonball, and it’s over 300 years old, but it’s still the best way to build intuition.

Imagine a cannon on top of an enormously tall mountain, high enough to be above Earth’s atmosphere (so we can ignore air resistance for the moment).

• Fire the cannon weakly. The cannonball travels a bit, then curves down and hits the ground. Ordinary projectile motion — the kind you learned about in high school physics.
• Fire it harder. It travels farther before hitting the ground. Still curves down, just later.
• Fire it hard enough, and something remarkable happens: the cannonball falls toward Earth, but Earth’s surface is curving away underneath it at the same rate the cannonball is falling. The cannonball never gets any closer to the ground. It just keeps falling, forever, around and around the planet. That is an orbit.
• Fire it even harder, and the cannonball’s path curves so gently compared to Earth’s surface that it escapes entirely, sailing off into space, never to return. That threshold speed is called escape velocity — for Earth, it’s about 11.2 km/s (roughly 25,000 mph) measured from the surface.

There is no magic “anti-gravity” trick to orbiting. There is no altitude where gravity switches off. Orbiting is just falling, combined with moving sideways fast enough that the curve of your fall matches the curve of the planet you’re falling around. This is why the phrase “satellites escape Earth’s gravity” is one of the most common — and most wrong — statements in casual science writing. Satellites don’t escape gravity. They are captured by it, in a very specific, elegant, endlessly repeating way. Gravity is the reason satellites stay up, not the thing they’re avoiding.

Now for the numbers, introduced gently, one variable at a time.

The velocity needed to maintain a stable circular orbit at a given altitude is called the orbital velocity, and it follows this relationship:

v = √(GM / r)

Let’s unpack every symbol:

• v — orbital velocity (how fast the satellite must travel, sideways, relative to Earth's center)
• G — the gravitational constant, a fixed number describing how strong gravity is, universally, for any two masses in the universe
• M — the mass of the body being orbited (Earth, in our case)
• r — the distance from the satellite to the center of Earth (not the surface — this trips people up constantly; you always measure from the center)

Notice the shape of this equation: as r gets bigger (higher altitude), v gets smaller. This might feel backwards at first — shouldn't you need to go faster to reach higher orbits? You need more energy to get there, yes, but once you're there, you need less speed to stay in a stable orbit, because gravity is weaker at that distance and doesn't need as much sideways speed to be "balanced" by the fall. This is why the International Space Station (about 400 km up) zips around Earth in about 92 minutes at roughly 7.66 km/s, while a GPS satellite (about 20,200 km up) takes about 12 hours at only about 3.9 km/s. Higher and slower.

Common Misconception #1: “There’s no gravity in space.”

This is probably the single most misunderstanding about orbital mechanics, and by now you have everything you need to dismantle it yourself. At the ISS’s altitude, Earth’s gravity is only about 10% weaker than it is at sea level. If gravity really did switch off in orbit, the ISS wouldn’t float gently — it would fly off in a straight line, per Newton’s First Law, and never come back. The reason astronauts float has nothing to do with gravity being absent, and everything to do with the ISS and everyone inside it falling together, at the same rate, in the same direction — which is exactly what an orbit is.

Common Misconception #2: “A rocket needs to go up to reach orbit.”

Getting to orbital altitude is actually the easy part, energetically speaking — a rocket could reach the ISS’s altitude with a small fraction of the fuel a real launch requires. The hard part, and the part that consumes the overwhelming majority of a rocket’s fuel, is achieving orbital velocity — that sideways speed of roughly 7.8 km/s needed so the fall around the Earth never stops curving into the ground. This is why rockets don’t fly straight up; after an initial vertical climb to get clear of the thick lower atmosphere, they pitch over and spend most of their remaining fuel accelerating sideways, not upward. A capsule that went straight up to ISS altitude and stopped would simply fall straight back down — it needs that sideways velocity to convert a fall into an orbit.

Types of Satellite Orbits

Different missions need different orbits, and the choice of orbit is arguably the single most consequential engineering decision in a satellite’s entire design, because it dictates power cycles, communication windows, coverage area, radiation exposure, and mission lifetime all at once.

A few of these deserve extra unpacking:

LEO is the neighborhood most people picture when they think “satellite,” and it’s where most of the exciting engineering (and most of your future satellite software) will live. It’s close enough to Earth for low-latency communication and high-resolution imaging, but it also means the satellite is moving so fast — around 7.5 km/s — that any single ground station can only “see” it for a handful of minutes before it disappears over the horizon. This single fact drives an enormous amount of software architecture in LEO missions: you cannot assume a constant connection to your spacecraft. You get short, scheduled windows, and everything — command uplinks, telemetry downlinks, software updates — has to be batched and scheduled around them.

GEO, by contrast, trades that responsiveness for permanence: because its 24-hour period exactly matches Earth’s rotation, a GEO satellite appears to hover motionlessly over one point on the equator, forever. A ground station can maintain a continuous, always-on link. This is why your satellite TV dish doesn’t need to move — it’s pointed at a single fixed spot in the sky and never has to track anything.

Sun-synchronous orbits are a beautiful piece of engineering that exploits a subtlety we haven’t discussed yet: Earth isn’t a perfect sphere — it bulges slightly at the equator — and that bulge causes orbits to slowly rotate over time. Sun-synchronous orbits are deliberately tuned so that this natural precession exactly cancels out Earth’s motion around the Sun, meaning the satellite crosses any given latitude at the same local solar time, orbit after orbit, year after year. For Earth-imaging missions, this is enormously valuable: every image of a given location is taken under nearly identical lighting conditions, making comparisons over time (deforestation, urban growth, glacier retreat) dramatically easier.

Lagrange points are a genuinely delightful piece of physics: five specific locations in a two-body system (like Sun-Earth) where the gravitational pull of both bodies combines with orbital motion to create a spot where a spacecraft can “park” with minimal fuel, staying roughly fixed relative to both bodies. The James Webb Space Telescope sits at Sun-Earth L2, about 1.5 million kilometers from Earth, on the side away from the Sun — far enough to keep the Sun, Earth, and Moon all behind it, giving its heat-sensitive infrared instruments a clear, cold view of deep space.

Anatomy of a Satellite

Every satellite, from a shoebox-sized CubeSat to a school-bus-sized GEO communications platform, is built from roughly the same set of subsystems, and each subsystem generates its own stream of telemetry that you, as a software engineer, will eventually need to interpret.

┌─────────────────────────────────────────────┐
│                   PAYLOAD                    │
│   (the reason the satellite exists — camera, │
│    radio transponder, science instrument...) │
└─────────────────────────────────────────────┘
                       │
┌──────────────────────┼──────────────────────┐
│                       ▼                      │
│        ONBOARD COMPUTER (flight software)    │
│   schedules, commands, telemetry collection  │
└──────────────────────┬──────────────────────┘
     │            │            │            │
     ▼            ▼            ▼            ▼
┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐
│  POWER  │  │  ADCS   │  │ COMMS   │  │ THERMAL │
│ solar + │  │attitude │  │antennas,│  │ heaters,│
│battery  │  │determin.│  │ radios  │  │radiators│
│         │  │& control│  │         │  │         │
└─────────┘  └─────────┘  └─────────┘  └─────────┘

• Payload — whatever the mission actually exists to do. A camera for Earth imaging, a radio transponder for communications, a spectrometer for science. Everything else on the satellite exists purely in service of keeping the payload alive and functioning.
• Power system — solar panels convert sunlight to electricity; batteries store energy for use during eclipse. This is the subsystem behind our 3 a.m. story, and arguably the single most important subsystem to monitor, because every other subsystem depends on it.
• Onboard computer (flight software) — the “brain,” running the software that schedules operations, executes commands from the ground, and manages telemetry collection.
• Communications (comms) — antennas and radios that talk to ground stations. Includes both the science/payload downlink (often high-bandwidth) and the housekeeping/command uplink (often low-bandwidth but mission-critical).
• ADCS (Attitude Determination and Control System) — determines which way the satellite is pointing and controls its orientation, using sensors (star trackers, sun sensors, gyroscopes) and actuators (reaction wheels, magnetorquers, thrusters). This is what keeps solar panels facing the sun and antennas facing the ground station.
• Sensors — beyond ADCS sensors, satellites carry sensors for temperature, radiation, current, voltage — the raw material of housekeeping telemetry.
• Thrusters — small engines for orbit adjustments (station-keeping, collision avoidance, deorbit at end of life).
• Thermal systems — heaters, radiators, and insulation that keep every component within its operating temperature range, which is a genuinely difficult problem given that one side of a satellite might be in blistering direct sunlight while the other side radiates heat into the near-absolute-zero cold of deep space.

Each of these subsystems produces its own telemetry stream, and — this is the important part for you — nearly every one of those streams has some dependency on orbital position. Power telemetry depends on eclipse status. Thermal telemetry depends on sun angle. ADCS telemetry depends on where the satellite needs to be pointing relative to the ground station or target. Comms telemetry depends on which ground station is currently in view. There is no subsystem on a spacecraft whose telemetry can be fully understood without an orbital reference frame.

To make this concrete, here’s a sample of what each subsystem actually reports back, and — for each one — the orbital fact you need on hand to interpret it correctly:

Telemetry Explained

Telemetry, at its root, just means “measurement from a distance” (from Greek roots meaning “far” and “measure”). If you’ve worked with any modern observability stack, the concepts will feel instantly familiar, wearing slightly different clothes.

• Metrics — numeric time-series data: battery voltage, temperature, spin rate, signal strength. Exactly like the metrics you’d send to Prometheus or Datadog, except sampled onboard and stored until there’s a communication window to send them down.
• Logs — discrete text or structured records of events: “Command received,” “Solar panel deployed,” “Watchdog reset triggered.” Same concept as application logs, just generated by flight software instead of a web server.
• Events — significant, often state-changing occurrences: entering eclipse, acquiring ground station signal, completing a maneuver. Think of these as analogous to Kubernetes events or CloudWatch events — structured markers of “something notable just happened.”
• Commands — instructions sent up to the spacecraft (this is the one direction of data flow that has no clean analogy in typical web observability, since we’re used to systems that respond to commands nearly instantly; here, a command might not execute for hours, and confirmation of execution might take even longer).
• Housekeeping data — the general term for all the “is the spacecraft bus healthy” telemetry: voltages, currents, temperatures, attitude, memory usage — as opposed to payload data (the actual mission data, like images or science readings).
• Health monitoring — automated systems (onboard and on the ground) that watch housekeeping data against expected ranges and flag anomalies — the spacecraft equivalent of alerting rules.

The flow of telemetry, end to end, typically looks like this:

[Spacecraft Sensors] 
        │
        ▼
[Onboard Data Handling / Storage]
   (buffered — no ground contact right now)
        │
        ▼   (only during a ground station pass)
[RF Downlink] ──► [Ground Station Antenna]
        │
        ▼
[Mission Operations Center]
        │
        ├──► [Telemetry Database]
        ├──► [Health Monitoring / Alerting]
        └──► [Dashboards for Operators]

The critical difference from a typical web-service telemetry pipeline: the pipeline isn’t continuous. Data piles up onboard, sometimes for hours, and arrives in bursts whenever a ground station window opens. If you design your alerting logic assuming telemetry arrives in a smooth, continuous stream — the way it would from an EC2 instance — you’ll build a system that’s confused by its very nature, flagging “gaps” that aren’t outages at all, just the normal rhythm of orbital communication windows.

Ground Stations

A ground station is an antenna installation on Earth that talks to a satellite as it passes overhead. Because Earth is (mostly) opaque and satellites move quickly across the sky, any single ground station can only communicate with a LEO satellite during a pass — a window of a few minutes, a handful of times per day, when the satellite is above the local horizon.

Several physical realities shape how this works:

• Communication windows are calculated in advance directly from the satellite’s ephemeris mission planning software predicts exactly when a satellite will rise above a ground station’s horizon, how high it will get, and when it will set again.
• Signal propagation takes time — light (and radio waves) travel at a fixed, finite speed. For LEO, this delay is small (a few milliseconds), but it’s not zero, and it needs to be accounted for in any time-sensitive command sequence.
• Doppler shift — because the satellite is moving rapidly relative to the ground station (fast approach, then fast recession), the frequency of its radio signal shifts, exactly like the pitch of an ambulance siren changing as it passes you. Ground station software has to continuously retune to track this shifting frequency throughout the pass, or the link degrades and can drop entirely.
• Tracking — ground station antennas often have to physically (or electronically) steer to follow the satellite across the sky in real time, since the pass only lasts minutes and the satellite can move dramatically across the visible sky in that time.
• Mission Operations Centers (MOCs) — the facilities where humans (and increasingly, automated systems) monitor spacecraft health, schedule commands, and respond to anomalies, tying together ground station scheduling, telemetry processing, and command generation into one coordinated operation.

Orbital Mechanics Meets Observability

Traditional observability — the kind built for cloud-native web services — is built on an implicit assumption: the environment is roughly constant, and deviations in metrics reflect changes in your software or your traffic. CPU usage spikes because of a code deploy or a traffic surge. Latency increases because of a database issue. The “ground truth” you’re comparing against is mostly your own system’s history.

Satellite telemetry breaks that assumption completely, because the environment itself is constantly, predictably, dramatically changing — on a schedule dictated entirely by orbital mechanics. Consider everything that changes, purely as a function of where the satellite physically is right now:

• Eclipse status — power generation swings from full solar output to zero, and back, every single orbit.
• Sun angle — even outside of full eclipse, the angle between the sun and the solar panels changes continuously as the satellite moves and rotates, directly affecting power generation and thermal load.
• Latitude / geomagnetic position — radiation environment changes dramatically depending on whether a satellite is passing through regions like the South Atlantic Anomaly (a region where Earth’s magnetic field dips unusually low, exposing satellites to elevated radiation and higher rates of computer bit-flips and glitches).
• Altitude variations (for elliptical orbits) — atmospheric drag, thermal environment, and available observation geometry all shift between perigee and apogee.
• Space weather — solar flares and geomagnetic storms can spike radiation levels, degrade GPS accuracy, and even increase atmospheric drag on LEO satellites by heating and expanding the upper atmosphere.
• Ground station visibility — whether the spacecraft is even in contact with the ground right now, which determines whether a “gap” in telemetry means an outage or simply means nobody’s listening at the moment.

Here’s a comparison table that I think crystallizes the difference:

The practical engineering implication: a genuinely useful satellite observability system needs an orbital context layer sitting underneath every dashboard and every alert rule — a layer that continuously answers questions like “is this satellite in eclipse right now?”, “is it currently in view of a ground station?”, “what’s the sun angle on this face of the spacecraft?”, and “is it passing through an elevated-radiation region?” Without that layer, every alert rule is guessing, and every on-call engineer is stuck doing the mental math our battery-alert story started with — by hand, at around 3 a.m., under pressure.

A worked mission-operations scenario. Let’s put this into practice with a slightly more involved version of the story that opened. Suppose your dashboard shows three simultaneous events at 3:14 a.m.:

1. Battery state of charge drops from 95% to 60% over 30 minutes.
2. Solar panel current reads 0.0 A.
3. Panel temperature drops sharply, from +40°C to –15°C.

Read in isolation, each of these looks like a plausible emergency: a battery fault, a solar panel failure, a thermal control failure. Read together, with orbital context layered underneath, a very different — and far more mundane — story emerges: all three signatures are the textbook fingerprint of entering eclipse. Zero solar current is expected, because there’s no sunlight hitting the panels. The temperature drop is expected, because the panels are radiating heat into space with no sunlight to replace it. And the battery drop is expected, because the spacecraft has switched, automatically and correctly, from solar power to battery power. An operator armed with an eclipse-status feed can dismiss all three alerts in seconds, with full confidence, instead of spending twenty adrenaline-soaked minutes manually cross-checking each one against an orbit propagator by hand.

Now contrast that with a genuinely dangerous version of the same scenario: the exact same three telemetry drops, but occurring while the orbital context layer reports the satellite is firmly in full sunlight. Now there is no benign explanation available, and the alert deserves every bit of urgency the original 3 a.m. page implied. This is the real value of orbital-aware observability — not that it silences alerts, but that it tells you, instantly and automatically, which alerts are actually alarming and which ones are just the ordinary rhythm of a spacecraft doing exactly what physics predicts it should do.

This orbital context layer isn’t exotic technology. It’s a direct software application of everything given a satellite’s orbital elements (the numbers describing its ellipse, from Kepler’s First Law), you can compute its position at any moment, cross-reference that position against the Sun’s position (to determine eclipse and sun angle) and against known ground station coordinates (to determine visibility windows) and against models of Earth’s magnetic field (to flag elevated-radiation regions). None of the physics is new. What’s often missing is the plumbing — the software layer that quietly, continuously joins orbital state to every telemetry point, so a human being never again has to manually reconstruct “oh wait, it’s probably just eclipse” under pressure.

AI for Satellite Operations

As constellations grow from single spacecraft into fleets of hundreds or thousands, human operators simply cannot manually watch every telemetry stream, and this is where AI and machine learning are becoming central to modern mission operations, in a handful of specific, well-defined roles:

• Predictive maintenance — using historical telemetry patterns to forecast component degradation (battery capacity fade, reaction wheel wear, solar panel efficiency loss) before it becomes a critical failure, rather than reacting after a threshold is crossed.
• Anomaly detection — statistical and machine-learning models that learn a spacecraft’s normal orbital-context-aware baseline (accounting for eclipse cycles, sun angles, and radiation regions) and flag deviations from that baseline, rather than relying on simplistic static thresholds that don’t understand the periodic nature of spacecraft telemetry.
• Mission copilots — LLM-assisted tools that let operators ask natural-language questions of a fleet (“which satellites had an anomalous battery discharge during their last three eclipse periods?”) instead of hand-writing complex queries against telemetry databases.
• Autonomous spacecraft — onboard software making certain operational decisions (safe-mode entry, collision-avoidance maneuvers, opportunistic payload scheduling) without waiting for a ground command, because the communication delay or gap makes waiting impractical.
• Digital twins — high-fidelity software simulations of a spacecraft’s physical and orbital behavior, used to test commands and predict outcomes before sending anything to the real, unrepeatable, hardware in orbit.

The theme connecting every one of these applications is the same one that’s run through this: the models are only as good as the orbital context they’re built on. An anomaly-detection model that doesn’t know a battery discharge is expected during eclipse will flag every single orbit as anomalous, and quickly get ignored by exhausted operators — a satellite-scale version of alert fatigue. The single highest-leverage thing an AI system for spacecraft operations can do isn’t a fancier algorithm; it’s simply knowing where the satellite is, physically, in its orbit, at every point in time — the same orbital context layer, now feeding a model instead of a dashboard.

The Future

A few trends are reshaping what “satellite operations” even means, and each one deepens the case rather than making them less relevant:

• Mega-constellations — companies are now operating constellations with thousands of satellites (Starlink alone has launched well over 7,000), a scale at which manual, per-satellite human monitoring becomes structurally impossible, and orbital-context-aware automation stops being a nice-to-have and becomes a hard requirement.
• Space traffic management — as low Earth orbit fills up, tracking and predicting the positions of tens of thousands of active satellites and pieces of debris — using exactly the orbital mechanics covered in this is becoming a discipline in its own right, with real safety and regulatory stakes.
• Autonomous satellite fleets — spacecraft that coordinate with each other directly, making formation-keeping and collision-avoidance decisions onboard, without waiting on ground control, because at fleet scale, the communication bottleneck makes centralized, human-in-the-loop control impractical.
• AI-assisted mission operations — copilots and anomaly-detection systems, maturing from research projects into standard operational tooling across the industry.
• Software engineers entering the space industry — the barrier to entry for building satellite software has dropped enormously in the last decade. Launch costs have fallen, CubeSats and small-satellite platforms have commoditized the hardware, and the software — flight software, ground systems, telemetry pipelines, observability, AI — is where an enormous amount of the remaining differentiation and opportunity now lives. This is, genuinely, a moment where the skills you already have as a software engineer — distributed systems thinking, observability instincts, AI/ML tooling — are directly transferable, and often in short supply, in an industry that historically drew almost exclusively from aerospace engineering backgrounds.

Orbitlogs is a personal project I’m building: an observability platform designed specifically for satellite operations. Unlike traditional monitoring tools that treat telemetry as isolated metrics, Orbitlogs understands the orbital context behind every data point. By correlating telemetry with orbital position, eclipse status, ground station visibility, sun angle, and space weather, it helps mission operators distinguish expected spacecraft behavior from genuine anomalies, reduce false alerts, and accelerate incident response.